From kontola@nmpiesO1tr.nmp.nokia.com Thu Jun 15 05:47:20 1995 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id FAAQ6719 for 
<hfsig@tapr.org>; Thu, 15 Jun 1995 05:47:15 -0500 
Received: from saedai1.nmp.nokia.com (saedai11.nmp.nokia.com [131.228.240.201]) by 
noknic.nokia.com (8.6.9/8.6.9) with SMTP id NAA15101 for <hfsig@tapr.org>; Thu, 15 
Jun 1995 13:45:14 +0300 
Received: from ms-smtp-gw.nmp.nokia.com by saedai1.nmp.nokia.com with SMTP 
(1.37.109.8/16.2) id AAQ2056; Thu, 15 Jun 1995 13:46:06 +0300 
Received: by ms-smtp-gw.nmp.nokia.com with Microsoft Mail 
id <2FEQ1D36@ms-smtp-gw.nmp.nokia.com>; Thu, 15 Jun 95 13:44:54 gmt 
From: "Kontola Ilkka (NMP)" <kontola@nmpiesO1tr.nmp.nokia.com> 
To: hfsig <hfsig@tapr.org> 
Subject: some questions 
Date: Thu, 15 Jun 95 13:41:00 gmt 
Message-Id: <2FE01D36@ms-smtp-gw.nmp.nokia. com> 
Encoding: 37 TEXT 
X-Mailer: Microsoft Mail V3.0 


This is my first posting to the list so please forgive me my ignorance. 


What kind of delay spread there is on NVIS paths? The ground wave could be 
one path but is there ionospheric multipath modes in NVIS (of course in 
addition to the _wanted_ ionospheric refraction/reflection)? 


I have no hands-on experience on _HF_ digital modulations - exept CW ;-). 


In literature there are often casual comments ".... on 3.5 MHz packet the 
multipath is very severe problem ...." and so on. Are the article/book 
authors 

referring to DX or multi-hop paths or shorter ranges? 


Pointers to existing DSP5600X classic modem codes (RTTY, AMTOR, PACTOR, 300 
bps FSK / "HF packet") as well as a pointer to a PC PACTOR program 
(requiring only a modulator and demodulator) would be appreciated! 


I would like to get some feeling about the classic HF digital modes but I 
dont want to spend much time coding soon-to-become-obsolete modems and 
protocol software. 


Is anyone working with adaptive equalizer -based HF modem? 


BTW I have two DSP56000-family development systems: 
- Ariel PC-56 (an ISA card with a 14-bit codec and a 20 MHz 56001) 
- DSP56002EVM (two days old.... not much experience yet) 


73, 
Ilkka OH3NIC 


KIKI IKK IKK KAI IKI KKK III III KK III KIKI III IKI IKK III III III III IIIA III 
Ilkka Kontola E-Mail: ilkka.kontola@nmp.nokia.com 
Nokia Mobile Phones 


Cellular Data 
Tampere, Finland 


From FORRERIJ@frl.orst.edu Thu Jun 15 10:50:29 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAAQ8573 for 
<hfsig@tapr.org>; Thu, 15 Jun 1995 10:50:25 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id IAA22721 for <hfsig@tapr.org>; Thu, 15 Jun 1995 
08:49:52 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Thu, 15 Jun 95 8:56:05 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 15 Jun 95 8:55:57 
PST8PDT 
From: "Johan Forrer" <FORRERIJ@fr1l.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Thu, 15 Jun 1995 08:55:52 PST8PDT 
Subject: Re: [HFSIG:400] some questions 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <27F55CEQCO8@fr1l.orst.edu> 
Dear Ilkka, 
To be honest, I don't really know what "NVIS" means - can anyone help? 


Just for interest sake, you may find it useful to browse the files in 
ftp.tapr.org /tapr/SIG/hfsig/upload 

There are quite a bit on HF propagation; as related to it's affects on 
digital transmissions. 


You will also find two Pactor programs there, one that I wrote "PSATOR/PSA- 
PACTOR" for the sound card DSP, and another one by Tom Sailer, HB9JNX, that 
will work with a number of different types of modems, including something 
that you can put together on your new EVM56002. 


I have ported the Alef Null kernel to the EVM56002 and thus allows you 

to run any of the codes that run on the DSPCARD4. This includes 1200 baud 
BELL 202 and 9600 baud PAM (G3RUH) style modems. The DSP kernel includes 
all HDLC and KISS interfaces, so all you need to have is the EVM and 

one of the flavors of NOS/KA9Q on your PC. It's really neat stuff. For the 
HF side of things, I have some HF modems for the EVM as well. 


Using the ported kernel, you will also be able to participate in the 
experimental high speed HF modem work. There also are a number of 
excellent noise reduction programs using Wiener, LMS and correltion- 
based algorithms. The latter is by Pawel (SP9VRC) and is a joy to use on 
CW. 


I am working on putting together the schematic for my version of the EVM's 
radio interface and will post the complete package (with the kind 
permission of the Alef Null group) on the net. Watch for the announcement if 


you are interested. 


Think this answers most of your questions. Feel free to e-mail me directly 
about the EVM56002. 


73's 


--Johan, KC7WW 

(email: forrerJ@ucs.orst.edu) 

From n7oo@hereford.ampr.org Thu Jun 15 12:45:55 1995 

Received: from usacec-osigw.army.mil (usacec-osigw.army.mil [137.80.1.10]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id MAA09383 for 

<hfsig@tapr.org>; Thu, 15 Jun 1995 12:45:42 -@500 

Message-Id: <199506151745 .MAA09383@dingus.n5lyt.datarace.com> 

Received: from slip1.cec.army.mil by usacec-osigw.army.mil id aa00430; 
15 Jun 95 17:19 MST 

X-Sender: jtaylor@usacec-osigw.army.mil 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Thu, 15 Jun 1995 10:41:18 -0700 

To: hfsig@tapr.org 

From: Jack Taylor <n7oo@hereford.ampr.org> 

Subject: New Clover board 


Page 177 of the June 95 QST has an announcement from HAL on their new $395 
DSP modem, the P38. Understand this uses one of the TI chips and comes with 
software for clover, pactor, amtor, baudot and ascii. If packet could be 
ported to it, one would have a near ideal modem! 


73 de Jack 


From gjones@tenet.edu Thu Jun 15 13:06:55 1995 

Received: from beall.tenet.edu (Nadine-Ruth-Beall.tenet.edu [198.213.2.11]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id NAA09579 for 
<hfsig@tapr.org>; Thu, 15 Jun 1995 13:06:50 -0500 

Received: (from gjones@localhost) by beall.tenet.edu (8.6.11/8.6.9) id NAAQ6308 
for hfsig@tapr.org; Thu, 15 Jun 1995 13:06:47 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199506151806 .NAAQ6308@beall.tenet.edu> 

Subject: Re: [HFSIG:402] New Clover board 

To: hfsig@tapr.org 

Date: Thu, 15 Jun 1995 13:06:47 -0500 (CDT) 

In-Reply-To: <199506151745 .MAA09383@dingus.n5lyt.datarace.com> from "Jack Taylor" 
at Jun 15, 95 01:02:15 pm 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 748 


Very similar to the DSP-93 except that it has a 68000 processor on it and is 
a plug in card. 


So - to port code you have to program the 68000 and TI chip. Makes it much 


more fun. 


Bill Henry intro the unit at Dayton. Interesting unit. 
You can think of it as a scaled down clover board. 


I think Bill or someone from HAL is on the mail list - they could probably 
go into it in a lot more detail. 


Cheers - Greg 

According to Jack Taylor: 

Page 177 of the June 95 QST has an announcement from HAL on their new $395 
DSP modem, the P38. Understand this uses one of the TI chips and comes with 
software for clover, pactor, amtor, baudot and ascii. If packet could be 


ported to it, one would have a near ideal modem! 


73 de Jack 


VV VV VV VV WV 


From mcdermot@eagle.aud.alcatel.com Thu Jun 15 13:56:44 1995 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id NAA10072 for 
<hfsig@tapr.org>; Thu, 15 Jun 1995 13:56:41 -0500 
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AA11600; Thu, 15 Jun 95 13:56:39 CDT 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ2000; Thu, 15 Jun 95 13:56:38 CDT 
Date: Thu, 15 Jun 95 13:56:38 CDT 
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9506151856 ..AAQ2000@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:402] New Clover board 


> From hfsig@tapr.org Thu Jun 15 13:16:07 1995 
> Reply-To: hfsig@tapr.org 
> Page 177 of the June 95 QST has an announcement from HAL on their new $395 
> DSP modem, the P38. Understand this uses one of the TI chips and comes with 
> software for clover, pactor, amtor, baudot and ascii. If packet could be 
> ported to it, one would have a near ideal modem! 
> 
> 73 de Jack 
> 
> 
I talked with Bill Henry for a few minutes at Hamcom about the P38 
board, 
he said that the 320C25 runs at 50 Mhz., and it uses the 68360 Motorola 
processor. 


The 68360 has a 68020 core, and has several HDCL and other serial channels 
built 
in, plus DMA controllers -- the 68360 is a very powerful chip (we use them at 


work). 

The HAL P38 board will not work at the two highest speeds of CLOVER II. The 
Take 

chip does not have the capability of the Motorola 56000 that is used on the 
original 

CLOVER board. Many of the tricks in the 56000 are what made Clover run 
fast.. 


- Tom, N5SEG 

ips Nea fet Me ates ee MN ci ce Mal eee eh Nols Lt te Batches YING colton el een thes UN fe ET 
Tom McDermott | "All opinions expressed 
Alcatel Network Systems, Inc. | are my own, and do not 
mcdermot@aud.alcatel.com | represent those of Alcatel 

[ ICC'96 Technical Program Secretary ] | Network Systems, Inc." 

[ June 23-27, 1996, Dallas, Tx. ] | 
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From elvey@hal.com Thu Jun 15 15:30:10 1995 
Received: from hal.com (hal.COM [192.88.244.33]) by dingus.n5lyt.datarace.com 
(8.6.10/8.6.9) with SMTP id PAA10663 for <hfsig@tapr.org>; Thu, 15 Jun 1995 
15:30:05 -0500 
Received: from civic.hal.com by hal.com (4.1/SMI-4.1.1) 
id AA21815; Thu, 15 Jun 95 13:30:03 PDT 
Received: by civic.hal.com (4.1/SMI-4.1.2) 
id AAQ7941; Thu, 15 Jun 95 13:29:53 PDT 
From: elvey@hal.com (Dwight Elvey) 
Message-Id: <9506152029.AA07941@civic.hal.com> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:403] Re: New Clover board 
Date: Thu, 15 Jun 1995 13:29:53 -0700 (PDT) 
Mime-Version: 1.0 
X-Mailer: Ishmail 1.0.4-sun-950116 
Available via anonymous ftp from ftp.halsoft.com 


Greg Jones <gjones@tenet.edu> wrote: 


> 

> I think Bill or someone from HAL is on the mail list - they could probably 
> go into it in a lot more detail. 

> 

> Cheers - Greg 


Hi All 

I hope I'm not the one that Greg is refering to. I work for HaL Computer 
Systems. Other then our software company in Austin we are making a high 
end work station. No modems 8-) 


I'm not sure if I posted this stuff before but I have done some stuff 
that might be of interrest. I have used a DigiCom Systems modem, called 
the Connection 14.4+ SoftModem, as my development platform. The board 
has a MAFE that is primarily used for phone modems. Normally the MAFE 
has a phase lock loop that syncs to the various baud rates. It also 
has the ability to do various asyncronous sample rates up to 38.8K. 
This is the way I use it. The board has either a 2115 or a 2101 on 


it depending on the model and it has a full complement of loadable 

RAM in the program and data memory ( 14Kx24 & 14Kx16 ). These boards 

are still sold by a few people at about $60 to $80 each or one could 

get them used for about $35. I have written some tools for these, 
including a binary loader, that are available from ftp 
taygeta.oc.nps.navy.mil under /pub/Forth/Reviewed/DSP/ as dspkit.zip 

and hfrfax.zip. The hfrfax was a radio fax demodulator that I made 

using this platform. The assembler that I used for this was one of my own 
invention and may not be to all's liking. 

I also have one of the ADI's EZKIT Lites that I have written a DOS 
loader and uploader for. These are available from ftp ftp.analog.com 
under /pub/ as ezup1.zip and ezld1.zip. I intend to make a translator 
to change the ADI's x.EXE format into a format that can be loaded into 
the Connection board. This will allow one to work in the assembler 
that came with the EZKIT to write code to work on the Connection board. 
Only thing that one would have to watchout for would be not to use 
the few instructions that are only on the 2181 that comes with the kit. 
Dwight 


From chbrain@dircon.co.uk Thu Jun 15 16:31:39 1995 

Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA11153 for 

<hfsig@tapr.org>; Thu, 15 Jun 1995 16:31:24 -0500 

Received: by felix.dircon.co.uk id AA19041 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 15 Jun 1995 22:29:05 +0100 

Message-Id: <199506152129.AA19041@felix.dircon.co.uk> 

Received: from ad048.pool.dircon.co.uk(193.128.231.48) by amnesiac via smap (V1.3) 
id sma019031; Thu Jun 15 22:28:52 1995 

X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Thu, 15 Jun 1995 20:42:45 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 

Subject: Re: [HFSIG:401] Re: some questions 


>Dear Ilkka, 

> 

>To be honest, I don't really know what "NVIS" means - can anyone help? 

> 

It stands for Near Vertical Incidence Skywave and means the signal goes 

almost vertically up. The idea is to cut out the skip zone for tactical H.F 
communications rather than for strategic systems. It's all the thing in military 
circles at the moment. 


Regards Charles G4GUO. 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 


E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 
FAX +44 (0)1245 275448 


From ALAN_BLOOM@HP5300.desk.hp.com Thu Jun 15 17:43:49 1995 
Received: from hp.com (hp.com [15.255.152.4]) by dingus.n5lyt.datarace.com 
(8.6.10/8.6.9) with ESMTP id RAA11840 for <hfsig@tapr.org>; Thu, 15 Jun 1995 
17:43:41 -0500 
From: ALAN _BLOOM@HP5300.desk.hp.com 
Received: from opnmail3.corp.hp.com by hp.com with SMTP 
(1.37.109.16/15.5+ECS 3.3) id AAQ89266215; Thu, 15 Jun 1995 15:43:35 -0700 
Received: from by opnmail3.corp.hp.com with SMTP 
(1.37.109.8/15.5+ECS 3.4 Openmail) id AA27530; Thu, 15 Jun 1995 15:42:38 
-0700 
X-Openmail-Hops: 2 
Date: Thu, 15 Jun 95 15:40:00 -0700 
Message-Id: <"d0£, IARQOQ0Q0000*" @MHS> 
In-Reply-To: <"27F55CEQCO08(1)a(*«"@MHS> 
Subject: [HFSIG:401] Re: some questions 
To: hfsig@tapr.org 


>To be honest, I don't really know what "NVIS" means - can anyone help? 


"Near-Vertical Incident Skywave" -- It means a short-distance path 
(that would normally be covered by groundwave) that instead uses 
ionospheric reflection. There's been a lot of hype recently about 
"NVIS antennas" which are just antennas designed to minimize 

ground wave (low-angle) radiation. (i.e. the opposite of what 

you want for long-distance communication.) The advantage is that 
for short paths you get less fading, because there is no ground wave 
path to destructively interfere with the skywave. 


AL N1AL 
From sid@xm.doe.ernet.in Fri Jun 16 03:55:29 1995 
Received: from sangam.ncst.ernet.in (sangam.ncst.ernet.in [144.16.11.1]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id DAA17112 for 
<hfsig@tapr.org>; Fri, 16 Jun 1995 03:55:21 -0500 
Received: (from uucp@localhost) by sangam.ncst.ernet.in (8.6.12/8.6.6) with UUCP 
id 0AA18357 for hfsig@tapr.org; Fri, 16 Jun 1995 14:25:53 +0530 
Received: from doexm.UUCP by doe.ernet.in (4.1/SMI-4.1-MHS-7.0) 
id AA23548; Fri, 16 Jun 95 14:24:09+050 
Date: 15 Jun 95 10:02:14 IST (+0530) 
From: Siddharth Bhatachara <sid@xm.doe.ernet.in> 
To: hfsig@tapr.org 
Subject: Help. 
Message-Id: <A.805216833@xm.doe.ernet.in> 
X-Mail-Ref: 128 
X-Mailer: XMAIL 3.0 
Request-Delivery-Notification: true 


I have just become a subscriber of this wonderful mailing 


group and I find a lot of interesting things happening here. 


This is my first posting to the list. I need info on the 
following : 


1. The german pactor level-II modem PTC-II's availability. 
Whether the modem can be purchased in kit form or whether 
any documentation on its design is available. 


2. The PC-PACTOR software to operate Pactor with the AN-93 
modem which I intend to build. I could locate the PCTOR 
and download it from the tapr ftp site. Please let me know 
where from I can get the PC-PACTOR. 


Thanks and cuagn later. 


Siddhartha Bhattacharjee Internet : sid@mahavir.doe.ernet.in 
Senior Scientific Officer, Amateur Packet Radio : 

MAEP, C & I Division, vu2sid@vu2dpg.del.ind.as 
Room No. 3091,Department of Electronics, 

C.G.0. Complex, New Delhi Phone : 4363102 Ext.3491/4363112 


From 72253.2602@compuserve.com Fri Jun 16 08:46:15 1995 
Received: from arl-img-2.compuserve.com (arl-img-2.compuserve.com [198.4.7.2]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id IAA19201 for 
<hfsig@tapr.org>; Fri, 16 Jun 1995 08:46:10 -0500 
Received: by arl-img-2.compuserve.com (8.6.10/5.950515) 
id JAA18845; Fri, 16 Jun 1995 09:46:06 -0400 
Date: 16 Jun 95 09:44:16 EDT 
From: Peter Schulze <72253.2602@compuserve.com> 
To: TAPR-HFSIG <hfsig@tapr.org> 
Subject: Re: Help 
Message-ID: <950616134416_72253 .2602_EHJ113-5@CompuServe. COM> 


Hi everybody, 


In reply to Siddhartha Bhattacharjees questions the following articles 
about Pactor-2 maybe of general interest. These articles were first 
published by the ADRS Digital Journal. All rights belong to ADRS (now 
IDRA). IDRA agreed to the posting of these three articles on the Internet. 


As the articles are rather long i will send them in three different 
messages. 


The PTC-2 modems are avaible from SCS in Germany. 


SCS 

Rontgenstrasse 36 

63454 Hanau 

Tel/Fax: +49 6181 23368 


price is in the 1000$ range. 


At the Dayton Hamfest, Paccom and AEA anounced Pactor2 controllers 
for later this year. 


I do not have a pactor 2 modem, so i can't make any comments about the 
performance. Does anybody have experience with these units ?? 


73 
Peter Schulze TY1PS 


P.S. 

i pulled this out of the S92ZM mbo yesterday: 
TY1PS de S92ZM> 

Nr: 4469 To: PACTOR From: 7Z1AB 


p 


Ptc II QRV list 16/6/95 

R:950615/1334z @:0E4XBU.AUT.EU [WINLINK AUSTRIA] #:14091 

R:950616/1027z @:7Z1AB.#APL.SAU.AS [USEARS-Desert-Network-Pct-I&II] 
#:3617 

R:950616/1025z @:7Z1AB.#KAM.SAU.AS [LUSEARS-Desert-Network-Gtor-PORT]##:312 


UUUUUUU" UUUUUUU" UU" UUUUU" = UUUUUU" 
EIIIIUVo EIIUUVE? UUUo UUEIIUU" UUEIIUU" 
UUE? UUUE? EUUo UUUUUUUo0 UUUUUUE? 
UUE? UUUE? UUo UUETIUUo UUEIIUU" 
UUo UUUUUUU" UUo UUo UUo UUUUUUE? 
EI? EITIIII? EI? EI? EI? EIIIII? 
UNITED STATES EMBASSY AMATEUR RADIO SOCIETY 
UAAAAAA? UAAA? U UA? UAAAAAA? UAAAAAA? UA? UA? 
3 UAA? 3 A? U 3 3 3 3 3 UAA? 3 A? UA? 3 3 3 3 3 
3 AAAU 3 3 3 3 AAU 3 3 AAAU 3 3 3 3 3 3 AAU 3 
3 UA? UU 3 3 AA? UAU 3 UAA? 3 3 3 3 3 3 UA? 3 
3 3 3 A? UU A? 33 33 3 3 UW AAU 3 3 33 3 
AAU AAAU AAAAU AAU = AAU AAU AAAAAAAU AAU AAU 
22222222222222222222222222222222222222222222222222222 


This Stations are QRV in PACTOR Level I & II 


x Call * Amtor * Name x QRG-Mark x QTH/Remarks 


7Z1AB ZZAB Rudolf 14.080 USEARS (PctII=7Z1AB-L2) 2MB-BBS 


DF7ML DFML Alf Muenchen 
DK2YF DKYF Willi 14.090 Nuernberg 
DK5FH DKFH Armin 3.583.25 Maintal 
DK5FI DKFJ Gerd Wiesbaden 
DK7HN DKHN Juergen Spaichingen 
DK8NZ DKNZ Richard Hersbruck 
DKINQ DKNQ Walter Lindlar 


DL1AN DLAN Hans 7.039 Hofheim 


DL7LD DLLD Achim Berlin 
DL1IFAN DFAN Guenther 3.593 7.039 14.082 Frankfurt/Main 


DL1IFDJ DFDJ Karl 14.076 \MM Flying Germania II 

DL1GWX DGWX Charly 14.079 3.575 Sigmaringen 

DL1ZAM DZAM Martin 3.583.25 Maintal 

DLIZAV DZAV Rudolf 14.072.5 Karben or Bangkok/HS 2MB-BBS 
DL2FAK DFAK Tom 14.079 3.583.25 Hanau 

DL2GRF DGRF Frank 14.079 Offenburg 

DMEN DMEN Ingo Oberstaufen 

DL3MFH DMFH Gerd Muenchen 

DL3RCF DRCF Christian 14.076 Poppenricht 

DL4BCA DBCA Reinhard Bremen 

DL5YDJ DYDJ Joachim Boffzen 

DL6MAA DMAA Peter Mindelheim 

DJ7PO DJPO Joerg 14.079 Offenburg 

DJIVB DIVB Rolf 14.060.8 Oberhausen 

DIJOJV DIIV Nussi Muenchen 

DJOOW DJOW Roy 14.079 Offenburg 

EA5FIN EFIN Arthur 7.039 14.072/74/76.5 La Manga (PAOLAM) 
EA5XK EAXK Herbert Moraira (DL1VR) 
HBONP HBNP Fred Mutschellen 

HB9BDM HBDM Chris Umiken 

HB9BIO HBIQ Tad Nierderwil 

HB9COK HCOK Alfred 3.579 14.060 Mutschellen (on weekends) 
HB9EBW HEBW Werner Ruenenberg 

HB9LAR HLAR Chris 

JKIDNW JDNW Jo Nagoya/JA 

KB6BT KBBT Walter 14.073/78/79 21.073 California 

KB8LUJ KLUJ Phil 3.642 14.079 Ohio 

KR8R KKRR Gerhard 3.642 14.090 Ohio 

OEQERI OERI Helmut 3.583.25 Rieslern 

VE3BGE VBGE Mike 14.077/79 Toronto 13/14:00 

Utc 

VK6BCP VBCP Walter Perth 

W1BEL WBEL Gwyn Tampa/FL 

WOUWE WUWE Julius 7.035.6/79 14.073/79/85 21.079 Chicago 
WA2MFY  WMFY Pete (any SYS/2 frequency) New Jersey 
XE1HOS XHOS Henry Mexico 


Who is the next on this list...YOU ?? 
If you know some more Call's send update Info to SysOp 7Z1AB 


tnxs 73 de Rudolf HSO/DL1ZAV SysOp @7Z1AB.d#APL.SAU.AS 
TYLPS de S92ZM> 


From 72253.2602@compuserve.com Fri Jun 16 08:46:15 1995 

Received: from arl-img-2.compuserve.com (arl-img-2.compuserve.com [198.4.7.2]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id IAA19202 for 
<hfsig@tapr.org>; Fri, 16 Jun 1995 08:46:10 -0500 


Received: by arl-img-2.compuserve.com (8.6.10/5.950515) 
id JAA18849; Fri, 16 Jun 1995 09:46:07 -0400 
Date: 16 Jun 95 09:44:27 EDT 
From: Peter Schulze <72253.2602@compuserve.com> 
To: TAPR-HFSIG <hfsig@tapr.org> 
Subject: [HFSIG:404] Re: New Clover board 
Message-ID: <950616134426_72253 .2602_EHJ113-6@CompuServe.COM> 


Hi everybody, 

Bill Henry gave me one of the new P38 boards in order to make sure that my 
Express software 

works ok on it. The board runs well and caused no problems so far. I will post 
the technical 

specs tomorrow as i don't have them at hands now here. Amazingly my board does 
the two 

fast modes that apply amplitude modulation. Maybe i have an early board, and 
they cut that off later for commercial reasons. But this shows that the DSP is 
fast enough for that. 

more tomorrow... 


73 Peter TY1PS 


From 72253.2602@compuserve.com Fri Jun 16 08:46:32 1995 
Received: from arl-img-5.compuserve.com (arl-img-5.compuserve.com [198.4.7.5]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id IAA19230 for 
<hfsig@tapr.org>; Fri, 16 Jun 1995 08:46:26 -0500 
Received: by arl-img-5.compuserve.com (8.6.10/5.950515) 
id JAA13283; Fri, 16 Jun 1995 09:46:25 -0400 
Date: 16 Jun 95 09:44:51 EDT 
From: Peter Schulze <72253.2602@compuserve.com> 
To: TAPR-HFSIG <hfsig@tapr.org> 
Subject: Pactor 2 part 3 
Message-ID: <950616134450_72253 .2602_EHJ113-7@CompuServe.COM> 


PACTOR-II 
The new Dimension in Data Transmission Technology 
By Dr. Tom Rink, DL2FAK, and Hans-Peter Helfert, DL6MAA 


Part 3: Short Description of the PACTOR-II Protocol 


I. Introduction 


All new modes should provide significant improvements over existing systems, 
which must not only refer to the maximum throughput and the robustness. Other 
basic attributes, like signal bandwidth, required frequency accuracy and com- 
patibility to existing standards also have to be taken into consideration. 


Modulation and encoding methods that supply high throughput rates, e.g. 16- 
DPSK, normally suffer from a lack of robustness. On the other hand, systems 
distinguished by a high robustness, e.g. DBPSK combined with a rate 1/2 con- 


volutional code, only provide a low maximum throughput. Therefore adaptive 
digital modes have to be used, that apply different modulation and encoding 
methods depending on the channel quality. Just changing the symbol rate how- 
ever, leads to only little adaptivity and additionally results in variations 
of the bandwidth. In order to prevent any spillover in adjacent channels, the 
bandwidth should ideally always remain the same, regardless of whether a ro- 
bust or a fast data transmission is performed. As 500 Hz CW filters are very 
commonly used and due to the usual spacing of the mailbox frequencies on short 
wave, a maximum bandwidth of 500 Hz should not be exceeded. In addition, there 
should not be too high a demand placed on the transceiver used, regarding its 
frequency adjustment and stability. For optimum results, maximum frequency de- 
viations similar to FSK modes should be tolerated. This forces the use of po- 
werful tracking methods, which allow a link also to be established if the de- 
viation is up to +/- 80 Hz. Further, a new mode should be backwards compatible 
to an existing standard, preferably with automatic switching, in order to pre- 
vent a deficiency of QSO partners in the early stage. 

PACTOR-II meets all the above mentioned requirements. It is fully backwards 
compatible with the current PACTOR standard, as the initial link setup is still 
done in FSK. If both stations are capable of Level II, an automatic switching 
is performed. The PACTOR-II protocol basically uses a two-tone DPSK system with 
raised cosine pulse shaping, which reduces the required bandwidth to less than 
500 Hz. The maximum absolute transfer rate is 800 bits per second. Due to the 
improved on-line data compression, maximum effective throughput rates of more 
than 1200 bits per second can be obtained. PACTOR-II is thus the fastest short 
wave digital mode. Very efficient error control coding using a convolutional 
code with a constraint length of 9 and a real Viterbi decoder with soft deci- 
sion is applied at all speed levels, in addition to analog Memory-ARQ. PAC- 
TOR-II is also therefore, by far the most robust digital mode, which allows a 
link to be established and achieve a reasonable throughput in such poor propa- 
gation conditions that all other modes fail. In comparison with the current FSK 
PACTOR standard including analog Memory-ARQ, which had been the most robust 
digital mode until the release of PACTOR-II, a further gain of robustness of 
around 7 dB could be obtained. The following chapters describe some details of 
the PACTOR-II protocol. 


II. Structure and Timing of the PACTOR-II Frames 


Similar to the current FSK PACTOR standard, PACTOR-II is also a half-duplex 
synchronous ARQ system without any mark/space convention. It may thus be oper- 
ated in USB as well as LSB position of the transceiver. The initial link setup 
is still performed using the FSK (PACTOR-I) protocol, in order to achieve com- 
patibility to the previous level. If both stations are capable of PACTOR-II, 
an automatic switching to the higher level is performed. The basic PACTOR-II 
frame structure is similar to PACTOR-I. It consists of a header, a variable 
data field, the status byte and the CRC. The standard cycle duration does not 
differ from FSK PACTOR and is still 1.25 seconds, which is one of the require- 
ments to obtain easy compatibility to Level I. Longer Control Signals (CS) had 
to be applied to achieve a higher robustness for the acknowledgment signal, 
required due to the greater robustness of the data channel. The entire length 
of the standard packet had to be shortened to 0.8 seconds in order not to 
shorten the maximum possible propagation delay, which is thus still 170 milli- 
seconds. The requirements to operate PACTOR-II regarding the transmit delay 
and the receiver recovery time of the used equipment therefore remain unchanged 


in comparison with Level I. 


Due to the signal propagation delay, and equipment switching delays, PACTOR-II 
as well as PACTOR-I has in the standard mode a maximum range for ARQ contacts 
of around 20,000 km. As with PACTOR-I, a long path option is available also for 
PACTOR-II, enabling contacts up to 40,000 km. The sending station calls the 
partner station in ‘Long Path Mode'. Initial contact is established using the 
PACTOR-I FSK protocol as previously mentioned, but with a cycle time of 1.4 
seconds instead of 1.25. This longer cycle time allows for the much greater 
propagation delays found on ‘Long Path' contacts. The link then automatically 
switches to PACTOR-II, with the same cycle duration. In the new data mode (see 
below), timing is also automatically adjusted to obtain longer receiving gaps. 


Unlike the previous level, PACTOR-II additionally switches to longer packets 
if the data blocks are not filled up with idles, (i.e. if the transmitter buf- 
fer indicates that more information has to be transferred than fitting into 
the standard packets). If the information sending station (ISS) prefers to use 
long packets, it sets the long cycle flag in the status word. The information 
receiving station (IRS) then finally can accept the proposed change of the cy- 
cle duration by sending a CS6. This situation, for example, occurs when reading 
longer files out of mailboxes. The long packets are basically made up like the 
short ones, but consist of a larger data field, which may contain up to 2208 
bits of usable information. The length of these data packets is 3.28 seconds, 
which leads to an entire cycle duration of 3.75 seconds in this so-called data 
mode. 


When entering text manually in QSO traffic from operator to operator, the maxi- 
mum throughput of the standard mode is normally not used up, thus the required 
higher flexibility of the system is still available due to the short packets. 
The efficient use of longer data packets on short wave is generally only pos- 
sible, if powerful error control coding, with full frame interleaving is ap- 
plied to cancel out error bursts or short fading periods. As already mentioned, 
PACTOR-II uses a convolutional code with a constraint length of 9, a real Vi- 
terbi decoder and soft decision, in addition to analog Memory-ARQ. Due to the 
high coding gain and the resulting capacity of error correction without re- 
questing a repetition of the entire packet, a significant increase in the ef- 
fective throughput could be obtained. Proceeding from average bit error rates 
on short wave channels, simple block codes are usually unable to provide enough 
coding gain. This often leads to a decrease in speed when using longer data 
strings, as repetitions often cannot be avoided. For more details on these tech- 
nical foundations, see the first part of this series. 


PACTOR-II uses six different CS, each consisting of 40 bits, all having exactly 
the maximum possible mutual hamming distance of 24 bits to each other. They 
thus reach exactly the Plotkin boundary and also represent a perfect code. This 
allows the advantageous use of the Cross Correlation method for decoding, which 
is also a kind of soft decision, leading to the correct detection of even in- 
audible CS. This checking is not only confined to a simple binary principle. A 
complex analog test procedure is applied, using the fine detail data from the 
DSP, to evaluate the single CS received, as well as the information summed up 
in the Memory-ARQ buffer. Similar to Level I, CS1 and CS2 are used to acknow- 
ledge/request packets and CS3 forces a break-in. CS4 and CS5 handle the speed 
changes, and CS6 is a toggle for the packet length. All CS are always sent in 


DBPSK in order to obtain a maximum of robustness. 
III. Speed Levels and Error Control Coding 


As mentioned in the introduction, PACTOR-II uses a two-tone DPSK modulation 
system. Due to the raised cosine pulse shaping, the maximum required bandwidth 
is only around 450 Hz at minus 50 dB. ASK, which was also tested in the early 
stage, provided poorer results in weak conditions compared with a higher DPSK 
modulation, as different amplitude levels are more difficult to distinguish in 
noisy channels than more phase levels. Additionally, ASK increases the Crest 
Factor of the signal. For these reasons, it is not used in the final PACTOR-II 
protocol. Basic information on these items can also be found in the first part 
of this series. 


PACTOR-II uses instead, different DPSK modulation schemes and various code 
rates. The Crest Factor of the PACTOR-II signal is therefore only 1.45. The 
basic code used is an optimum rate 1/2 convolutional code with a constraint 
length of 9. Codes with higher rates, e.g. rate 2/3 and rate 7/8, can be de- 
rived from that code by so-called puncturing. Prior to the transmission, cer- 
tain of the symbols of the rate 1/2 encoded stream are 'punctured' or deleted, 
and not transmitted. At the receiving end, the punctured encoded bits are re- 
placed with 'null' symbols prior to decoding with the rate 1/2 decoder. The 
decoder treats these null symbols neither as a received '1' nor as 'Q', but as 
an exactly intermediate value. No information is thus conveyed by that symbol 
that may influence the decoding process. The coding performance of ‘punctured’ 
code operation nearly matches the coding performance of the best known classic 
rate 2/3 or 7/8 codes with a comparable constraint length, provided that the 
puncture pattern is chosen carefully. The major advantage of this approach is 
that a single code rate decoder (in our case a rate 1/2 decoder) can implement 
a wide range of codes. 

In the PTC-II, the Viterbi algorithm is implemented for decoding of the con- 
volutional code. Nevertheless, as already indicated in the first part, there 
are several different methods to decode the PACTOR-II signal, which require 
less processing power, but in return for this, also provide less coding gain. 
However, these methods at least allow compatibility to the PACTOR-II standard 
and may therefore be applied in cheaper hardware. 


The most robust PACTOR-II speed level employs DBPSK with rate 1/2 coding, which 
per cycle allows an absolute throughput of 5 bytes in the standard mode and 36 
bytes in the data mode respectively. In the next step, DQPSK with rate 1/2 co- 
ding is applied, which leads to an absolute throughput of 14 bytes in the 
standard mode and 76 bytes in the data mode. This is followed by 8-DPSK with 

a rate 2/3 coding, providing a throughput of 32 and 156 bytes per packet, re- 
spectively. Finally, in best propagation conditions, PACTOR-II applies 16-DPSK 
with a rate 7/8 coding, which allows the maximum throughput of 59 bytes ina 
short packet and 276 bytes in the data mode. The mentioned transfer rates are 
all net rates referring to 8-bit ASCII, which are calculated after the error 
control coding and all other protocol overhead. As data compression is usually 
active, these throughput rates must be multiplied by the compression factor. 
The effective speed is therefore considerably higher in practice. The speed 
levels are automatically chosen by the PTC-II, considering the link statistics 
and the actual channel quality, thus no user intervention is required. 


IV. On-line Data Compression 


Like in the previous FSK PACTOR system, automatic on-line Huffman data compres- 
sion is applied. Additionally, PACTOR-II uses run-length encoding and, as a 
further novelty, Pseudo-Markov Compression (PMC, see below). Compared to 8-bit 
ASCII (plain text) PMC yields a compression factor of around 1.9, which leads 
to an effective speed of about 600 bits per second in average propagation con- 
ditions in data mode. PACTOR-II is already around 3 times faster than PACTOR-I 
and 15 times faster than AMTOR on average channels. However, the maximum effec- 
tive speed in good conditions can exceed 1200 bits per second. As the PTC-II 
firmware automatically checks, whether PMC, Huffman encoding or the original 
ASCII code is the best choice, which depends on the probability of occurrence 
of the characters, there is no risk of losing throughput capacity. PACTOR-II 

is of course still able to transfer any given binary information, e.g. programs 
or picture- and voice files. In these cases the on-line data compression is 
automatically switched off. 


Ordinary Huffman compression exploits the 'one-dimensional' probability distri- 
bution of the characters in plain texts. The more frequently a character oc- 
curs, the shorter has to be the Huffman symbol that is assigned to the actual 
character. On the other hand, Markov compression can be considered as a ‘dou- 
ble' Huffman compression, since it not only makes use of the simple probabili- 
ty distribution, but of the ‘two-dimensional' probability. For each preceding 
character, a probability distribution of the very next character can be calcu- 
lated. For example, if the actual character is 'e', it is very likely that '‘'1i' 
or 's' occurs next, but extremely unlikely that an 'X' follows. The resulting 
probability distributions are much sharper than the simple one-dimensional dis- 
tribution and thus lead to a considerably better compression. Unfortunately, 
there are two drawbacks: Since for each ASCII character a separate coding table 
is required, the entire Markov coding table becomes impractically large. Addi- 
tionally, the two-dimensional distribution and thus also the achievable com- 
pression factor depends much more on the kind of text than the simple character 
distribution. 

We have therefore chosen a slightly modified approach which we called Pseudo- 
Markov Compression, because it can be considered as a hybrid between Markov- 
and Huffman encoding. In this variant, the Markov encoding is limited to the 

16 most frequent 'preceding' characters. All other characters trigger normal 
Huffman compression of the very next character. This reduces the Markov coding 
table to a reasonable size and also makes the character probabilities less cri- 
tical, since especially the less frequent characters tend to have unstable pro- 
bability distributions. Nevertheless, for optimum compression, two different 
tables for English and German texts are defined in the PACTOR-II protocol and 
automatically chosen by the PTC-II. 


V. Some Practical Aspects 


Similar to Level I, the tones of the PACTOR-II signal are spaced at 200 Hz. 
Their frequency may be defined freely in steps of 1 Hz by software command, as 
long as the shift remains 200 Hz. Thus you can easily switch between high- and 
low-tones, and also adjust any additionally required tone pair. This allows 
the utilizing of narrow CW filters in all transceivers that provide the option 
of activating the corresponding filters in the SSB mode. 

In the PACTOR-II system, the transferred information is swapped from one chan- 


nel (tone) to the other in every cycle. Unlike FSK systems, the link is thus 
not blocked when strong narrow band QRM completely overpowers one channel (e.g. 
CW or carriers), but only its maximum speed is reduced. Usual FSK systems with 
a mark/space convention and without Memory-ARQ have to fail in such cases, be- 
cause even if a so-called 'space-only' mode is applied, the strongest signal is 
automatically chosen. This always leads to a break-down of the link, as the QRM 
is stronger than the useful signal in the proposed case. 

PACTOR-II provides a comprehensive Listen-Mode, which is much more robust than 
known from PACTOR-I, because just the short header has to be received correct- 
ly, then the powerful error control coding can be fully utilized. Burst errors 
may be corrected also by monitoring stations and thus virtually do not affect 
the performance. The Unproto-Mode in PACTOR-II allows to choose between all the 
above mentioned speed and encoding levels. On the receiving side, the correct 
mode is detected automatically and therefore needs no user-adjustment. For ex- 
ample, a fast and very robust QTC mode can thus be achieved, when a message is 
transmitted in the Unproto-Mode using DBPSK with rate 1/2 coding. 


From 72253.2602@compuserve.com Fri Jun 16 08:46:39 1995 
Received: from arl-img-5.compuserve.com (arl-img-5.compuserve.com [198.4.7.5]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id IAA19241 for 
<hfsig@tapr.org>; Fri, 16 Jun 1995 08:46:33 -0500 
Received: by arl-img-5.compuserve.com (8.6.10/5.950515) 
id JAA13334; Fri, 16 Jun 1995 09:46:31 -0400 
Date: 16 Jun 95 09:45:14 EDT 
From: Peter Schulze <72253.2602@compuserve.com> 
To: TAPR-HFSIG <hfsig@tapr.org> 
Subject: pactor 2 part 2 
Message-ID: <950616134513_72253 .2602_EHJ113-8@CompuServe.COM> 


This article was originally published in the ADRS Digital Journal. 
PACTOR-II 
The new Dimension in Data Transmission Technology 
By Dr. Tom Rink, DL2FAK, and Dipl.-Ing. Martin Clas, DL1ZAM 


Part 2: Description of the PTC-II 


I. Introduction 


This second part of the PACTOR-II series explains the final version of the 
PTC-II hardware. As already indicated in the first part, the DPSK modulation 
system makes it mandatory to use a DSP as the interface to the short wave 
transceiver. Additionally, the convolutional coding with Viterbi decoder re- 
quires very high processing power, more than available in any existing modem 
on the Amateur Radio market. 

However, the many wishes, ideas and suggestions from the ranks of the Radio 
Amateurs, have finally led to the development of an even more complex and 
flexible unit than necessary to implement the PACTOR-II system. For example, 
it has been the wish of many for a long time, to be able to operate not only 
with usual digital HF modes, but also to cover VHF and UHF Packet Radio at 


the same time, with one unit. Unlike currently available in existing units, 

a comfortable built-in mailbox should allow simultaneous access from all com- 
munications channels with the same priority, for example in Packet Radio on 

23 cms with 9600 baud and on 70 cms with 1200 baud. Naturally, during this 
time no PACTOR or AMTOR connect on HF should be lost or ignored. This forces 
the use of a RISC (Reduced Instruction Set) processor for fast processing of 
the HDLC Packet protocols. As the majority of modern HF transceivers can be 
programmed via a serial interface, another wish that has slowly formed, is to 
use this feature for remote control of the transceiver. To set up a mailbox 
that scans various frequencies on HF, external computer and software is no 
longer required. Additionally, you could utilize your home based PTC-II whilst 
on the move, or from a remote location using Packet Radio. Instruct the HF 
transceiver to tune to a specific frequency, then to make a connect in PACTOR 
to a particular mailbox and read the messages. 

These and many more ideas have led to hardware of very high performance. Due 
to the use of signal processing, the PTC-II is very flexible, and allows a 
great variety of different applications to be implemented. These range far 
wider than those written of up to now. Those technically talented users can 
make their own programs and modules, which may be loaded via the serial inter- 
face into the flash memory of the PTC-II. The possible uses are almost unlimi- 
ted, as the PTC-II provides a complete, very high performance development plat- 
form for DSP and 68020 applications. From simple external control functions 
(e. g. automatically turning the antenna to the connecting station), or audio 
processing functions (e. g. super-steep sided FIR filters 400th order for CW, 
automatic N-times notch filters, etc.) right up to complex functions, like an 
audio spectrum analyser or extra operating modes, whether known or still to be 
invented, may be implemented. 

The PTC-II comes on the market in February 1995. However, as some of the com- 
ponents used, among them the new DSP chip, are still difficult to get and due 
to the great demand for the PTC-II, the time of delivery for a unit will ini- 
tially be about 6 weeks. 


II. The Processor Section 


As has been made clear in the introduction, to achieve simultaneous processing 
of three communications channels along with the signal coding of PACTOR-II, a 
powerful computer is essential. A 32-bit processor system has been designed, 
based on the new communications processor 68360 (QUICC) from Motorola. This 
processor contains an expanded 32-bit version of the well known 68020 CPU, as 
used in many powerful computers, together with four separate programmable se- 
rial communications ports, the so-called SCC's, implemented as a RISC proces- 
sor. Two of these SCC's serve as the interfaces to the Packet Radio modems. 
The third SCC is used as RS-232 interface to the terminal. A buffer chip 
MAX207A provides the correct RS-232 voltage levels. The baud rate to the ter- 
minal is detected automatically, but can also be determined by software com- 
mand. The last remaining SCC serves as interface to the HF transceiver for re- 
mote control purposes. Four RAM chips with 8 bits each are required, to cover 
the 32 bit wide data bus. These can vary between 4 times 32k x 8 up to 4 times 
512k x 8. The PTC-II can therefore have a maximum of 2 MB of static RAM, which 
plays a large part in running the mailbox and internal administration as well 
as external programs, that may be loaded into the PTC-II in addition to the 
operating software. In order to further expand the possible applications, the 
PTC-II may also contain additional dynamic RAM in the form of a 72 pin SIMM 


module of up to 32 MB. The operating system is to be found in a flash memory 
of up to 512kx8. Additionally, it is possible to load programs over the serial 
interface from the terminal, which would enable the PTC-II to do a totally 
different job, as already mentioned in the introduction. Operating parameters 
for the PTC-II that should be resistant even to a deep reset are also stored 
in the flash memory. Data in this kind of memory remains stored even when no 
voltage is applied, but contrary to an EPROM, it may be electrically erased 
and re-written whilst in circuit. That makes it very easy updating the system 
or running different programs on the PTC-II. A battery-backed-up real-time 
clock and other features of the previous PTC are of course still included. 


III. The HF Modem with Signal-Processor 


The 50 MHz version of the XC56156 DSP from Motorola forms the interface to the 
HF transceiver. As the clock frequency is programmable, it is automatically ad- 
justed to suit the work of the moment. For easy tasks, such as FSK, the proces- 
sing speed can be reduced, yielding a corresponding saving in energy. The DSP 
contains a built-in 16-bit digital to analog converter, with the help of which 
the audio output signal to the transceiver is generated, be it simple AFSK or 
the complex phase modulation of PACTOR-II. The output amplitude is also pro- 
grammable and may be set in the range between 10 and 4000 mV by software com- 
mand. The normally required 'Mic Gain' potentiometer is thus missing. It is 
also possible for the PTC-II to control the output power of the transceiver, 
so that the power to maintain the link may automatically be adjusted to an 
optimum value. No more power than needed being used, which not only saves on 
the electricity bills, but can considerably extend the life of transmitting 
components and additionally causes less interference to other stations. 

For the signal input, the DSP uses a Sigma/Delta analog to digital converter 
with a 16-bit dynamic range (14 bit effective), which enables the normally 
necessary Anti-Aliasing filter to be dispensed with. With the exception of the 
decoupling OP-AMP at the input and output of the DSP, no further components in 
the signal path are required. The DSP contains some built-in static RAM, which 
in the PTC-II, is further expanded with 4 additional, very fast, static RAM's. 
The size of this RAM is 64k-words (16 bit) and is not variable. This enables 
difficult algorithms, for example 4096 point FFT, to be used. As the DSP has 
direct access to the main processor data bus, it does not tie up an SCC. The 
exact receive frequency of PACTOR-II is very quickly and reliably adjusted by 
software, using a newly-developed tracking method. In addition, the DSP is 
able, through pulsing the up/down function (which almost every modern trans- 
ceiver has as microphone buttons) to automatically change the tuning for op- 
timum results. The up/down keys are simulated by transistors, which pull the 
respective connection to ground. 


IV. The PTC-II Power Supply 


The PTC-II contains two power supply input options. Either it may be supplied 
via a special DC input connector, or directly from the HF transceiver via the 
connecting cable and socket. The two options are decoupled via diodes and feed 
a switching regulator. This has a high efficiency, and generates the 5V supply 
for the digital section. The supply voltage can vary between 8 and 20 volts. 
The current requirement, due to the use of the switching regulator, is depen- 
dant upon the supply voltage and the Packet Radio modems used. The higher the 
supply voltage, the lower the current consumption. This reverse proportionality 


is due to the fact that the power consumed is a product of voltage and current, 
and must be virtually the same before and after the regulator. The efficiency 
of the regulator is almost unaffected by the value of the supply voltage. The 
power supply input of the PTC-II contains special filtering, so that the 
switching harmonics from the regulator cannot reach the outside world. The 
operating voltage is internally fused with a 5x20 mm fuse. Of course an extra 
fuse is delivered with each unit to prevent problems in countries with dif- 
ferent standards. 


V. The Display and Indicator Unit 


The display and indicator unit is built on a separate circuit board, and sits 
at right angles to the main board, connected by soldering pads. It carries a 
tuning indicator of 15 LED's, 15 further LED's to display the various operating 
parameters and a 10-character 5x5 dot matrix LED display. Most of the LED's, 
including the tuning indicator, are dual colour types, to increase the informa- 
tion densitiy and the ease of reading the display. The tuning indicator, for 
example, changes from red to green as soon as the tuning is optimum for the 
chosen operating mode. The 10-character LED display shows the operating mode 
and thus eases the display of any possible future update modes, as the PTC-II 
is more than sufficient for modes such as FAX, CLOVER-II, etc. Additionally, 
various status information as well as the call of connecting stations is also 
given on this display, thus in many cases there will be no need to switch on 

a terminal. The display is readable from a distance and from unsuitable view- 
ing angles. The brightness is programmable and can be adjusted by a software 
command. 


VI. The Packet Radio Modems 


The ability to operate Packet Radio with the PTC-II is an integral part of the 
operating system, and therefore available on all units. The PTC-II is, however, 
mainly an HF controller, and thus the Packet Radio modems are implemented as 
modules, to be plugged in if the need arises. This enables a certain amount of 
mechanical compactness (the entire PTC-II is approximately the size of a modern 
VHF mobile transceiver). It also prevents those who only need an HF system from 
being forced to pay for an unwanted Packet Radio modem. The PTC-II contains 
connectors in the form of double PCB strip headers, on to which the modems can 
be easily plugged as required. There is space provided for two modems, which 
are automatically sensed when present. Two types of Packet Radio modems will be 
offered. A simple and cheaper version using the well-known modem chip TCM3105 
for 1200/2400 baud, as well as a version with the XC56156 DSP chip. The DSP 
version is able to accomodate all baud rates from 300 to 9600 baud. The switch- 
ing is accomplished by a software command. DSP programming and the clock are 
supplied from the main board, so that, apart from the DSP chip itself, virtual- 
ly no extra components are required for the signal processing. Additionally, 
the DSP modem board has space for an EPROM and its own clock generator, as well 
as baud rate switching. These enable the modem board also to be used either as 
a stand-alone modem, or together with other equipment. It delivers the usual 
Packet Radio signals of RxD, RxClock, TxD, TxClock and DCD. It is thus compa- 
tible with all other Packet Radio systems. Even the connections to the double 
PCB strip header are compatible with the usual Packet Radio system standards. 


The Packet Radio boards are not initially available however. They will come on 


the market in the middle of 1995, together with the corresponding firmware up- 
grade for the PTC-II. 


VII. The PTC-II Construction 


The PTC-II is made up of two printed boards, a main board of 147x170 mm, and a 
front board which, as described above, contains the displays and is mounted at 
right angles to the main board. The main board is a 6-level multi-layer con- 
struction and contains internal ground and supply voltage areas. On the back 

is the DC input connector, an on/off switch, an 8 pin DIN connector for the HF 
transceiver, two 5 pin DIN connectors for Packet Radio, an 8 pin Mini-DIN sock- 
et for the transceiver control as well as a 9 pin SUB-D socket for the terminal 
connector. All DIN plugs are delivered together with the unit. Every single pin 
of every socket has its own filter in order to improve the HF rejection in 
strong RF fields, as well as to prevent unwanted radiation of electromagnetic 
energy. On the front is a row of 52 finger-pads for solder connection with the 
front board, a mounting method used on all SCS controllers. The construction is 
largely SMD. The flash memory and four static RAM's are socketed to enable easy 
system upgrades. The RS-232 interface chip is also in a socket to allow easy 
replacement in event of damage. The SIMM module, due to its construction, needs 
a holder without which it cannot be mounted. An 8 way DIL switch is also in- 
cluded so that various parameters may be set that should not be changed via 
software. The whole is enclosed in an aluminium profile case, well known from 
previous SCS-PTC's and many TNC's. Both front and rear of the case are silk- 
screen printed, at the front using three colours. The green and red lettering 
of the dual colour LED's explain their meaning when lighting green or red, 
respectively. 


From 72253.2602@compuserve.com Fri Jun 16 08:46:46 1995 
Received: from arl-img-5.compuserve.com (arl-img-5.compuserve.com [198.4.7.5]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id IAA19256 for 
<hfsig@tapr.org>; Fri, 16 Jun 1995 08:46:40 -0500 
Received: by arl-img-5.compuserve.com (8.6.10/5.950515) 
id JAA13366; Fri, 16 Jun 1995 09:46:39 -0400 
Date: 16 Jun 95 09:45:40 EDT 
From: Peter Schulze <72253.2602@compuserve.com> 
To: TAPR-HFSIG <hfsig@tapr.org> 
Subject: PACTOR-2 part 1 
Message-ID: <950616134539_72253 .2602_EHJ113-9@CompuServe. COM> 


This article was originally published in the ADRS Digital Journal. 
PACTOR-II 
The new Dimension in Data Transmission Technology 
By Dr. Tom Rink, DL2FAK, and Hans-Peter Helfert, DL6MAA 


Part 1: Basic Technical Information 


I. Introduction 


PACTOR was designed more than five years ago in Germany, in order to overcome 
the known disadvantages of AMTOR and Packet Radio. PACTOR is a cheap and re- 
liable means of fast, robust and error-free data transfer over short wave 
links, and which does not exceed the usual 500 Hz bandwidth limit for digital 
modes. 

For the first time, not only the complete ASCII character set, but any given 
binary information could be transferred over short wave, even in very poor pro- 
pagation conditions. Another aim of the system development was the utilizing of 
inexpensive and widespread hardware. Since 8-bit controllers without Digital 
Signal Processor chips (DSP's) were state of the art at that time, Frequency 
Shift Keying (FSK) had to be chosen as a modulation method. Up to now, PACTOR 
with analog Memory-ARQ is still the most robust digital mode used in Amateur 
Radio. It is also still the fastest FSK mode that fits into a 500 Hz channel. 
These may be some of the reasons that have made PACTOR a standard, which is not 
only included in virtually all short wave modems in the Amateur Radio market, 
but is also widespread in the commercial world. 

In the meantime however, more powerful CPU's and DSP's have been developed. 
Processing power that greatly exceeded the financial limits of the average 
Radio Amateur a few years ago, has dropped to an acceptable price. Some of the 
current high-end modems for short wave operation already include a DSP, and in 
a few years you can expect all new modems to contain these chips. The through- 
put within a 500 Hz channel, as well as the robustness of a system can still 

be dramatically improved, by using modulation methods different to FSK, com- 
bined with powerful error control coding algorithms. A new standard that takes 
advantage of the forthcoming hardware generation is thus required. 

These considerations have led to the development of PACTOR-II. This is not 
‘another new mode', but a fully backwards compatible improvement to the current 
PACTOR protocol, with automatic switching. As there are already several compa- 
nies interested in licensing PACTOR-II, the German development group made sure 
that an implementation in units different from the original PTC-II will also be 
possible. However, using a less powerful hardware means sacrificing at least a 
considerable part of the weak signal performance of the system. 


This is the first of a series of three parts that describes the PACTOR-II sys- 
tem and the ideas behind it. In this first chapter, we will just explain some 

important technical fundamentals that everybody has to be aware of, to under- 

stand the advantages of the new protocol. The second part describes the PTC-II 
hardware. The third part deals with details on the PACTOR-II protocol. 


II. Modulation Methods 
1. Frequency Shift Keying (FSK) 


FSK was the first teletype modulation method used, and is still by far the most 
widespread one. The information is encoded using rectangular pulses, represen- 
ted by an interleaved ON/OFF keying of two carrier frequencies. The symbol rate 
is defined as fraction 1/T, the so-called baud rate. T represents the symbol 
duration. In FSK systems, the typical wide spectrum that could be expected when 
modulating a rectangular baseband signal on a carrier, is cancelled out by a- 
voiding phase discontinuities between successive pulses. Thus only the main 
lobes around the two carrier frequencies are dominant. The amplitude of a 200 
baud signal at 500 Hz bandwidth is about 30 dB smaller than the amplitude in 
the center of the spectrum. If however, the baudrate is increased, the band- 


width of the main lobes will naturally also increase. A 300 Baud signal, for 
example, clearly exceeds the 500 Hz bandwidth, hence an ordinary CW filter 
cannot be applied without distorting the pulses. This greatly deteriorates the 
performance and thus also the Bit Error Rate (BER) of the system. Additionally, 
signals with higher baud rates suffer from a significant loss of immunity a- 
gainst time smearing (see below). For these reasons, 200 baud is commonly con- 
sidered to be the maximum useful symbol rate of 2-tone FSK systems, operating 
over short wave links. Additionally, with regard to the over-crowded frequen- 
cies, all new systems should generally require not just a narrow bandwidth, 
but provide an improved spectral efficiency to obtain a higher throughput. We 
have therefore to look for a different approach, instead of using FSK. 


2. Phase Shift Keying (PSK) 


In PSK systems, the phase of a signal is used as a means of the information 
transfer. However, as the HF propagation conditions sometimes change quite 
rapidly, it is very difficult to track the absolute phase of a signal. There- 
fore it has proven to be much more efficient to utilize the phase difference 
between successive pulses. This requires a slightly higher Signal to Noise 
Ratio (SNR), but in return, the resistance against multipath effects is drama- 
tically increased. Modulation that employs phase differences between succes- 
sive pulses to encode the information is called Differential Phase Shift Key- 
ing (DPSK). If there are only two possible phase differences, signalling logi- 
cal one and zero, the modulation is called Differential Binary Phase Shift 
Keying (DBPSK). If there are four possible phase differences, signalling logi- 
cal dibits, it is called Differential Quadrature Phase Shift Keying (DQPSK). 
For example, with an one-tone 100 baud DQPSK signal, 200 bit/sec. can be trans- 
ferred. If more phase differences are distinguished, the corresponding systems 
are called 8-DPSK, 16-DPSK, etc. 

As phase shift keying naturally implies phase discontinuities between succes- 
Sive pulses, the spectrum of a DPSK system with hard keying shows the typical 
strong side-lobes of a rectangular pulse spectrum. The amplitude of a hard- 
keyed 100 baud DPSK signal is only around 15 dB smaller at a cut-off frequency 
of +/- 250Hz than in the center of the spectrum. Thus hard keying must not be 
used on short wave due to the resulting large bandwidth. To avoid this problem, 
the baseband signal of a PSK system must be specifically prepared before it 
gets as far as being modulated on the carrier. This is done by transforming the 
rectangular pulses containing the binary information into suitable wave forms, 
using special shaping algorithms. H. Nyquist has designed a pulse with very 
useful properties, the so-called raised-cosine pulse, which does not produce 
any spectral spillover. These pulses do not produce any intersymbol interfer- 
ence either, since their amplitude is zero at the sampling time of successive 
pulses. Thus they can be overlapped without any interference between them, even 
if the pulses are four times longer than the corresponding rectangular pulses. 
This is the reason why a very high information density and a good spectral ef- 
ficiency can be obtained using raised-cosine pulses. Since a raised-cosine DPSK 
signal with a symbol rate of 100 baud only occupies a bandwidth of around 200Hz 
at -45 dB, it is obvious that two of these signals can be placed together into 
a 500HzZ channel. The resulting system is called two-tone-DPSK. It can robustly 
transfer 400 bit/sec. within a bandwidth of less than 500Hz, if DQPSK is ap- 
plied or up to 600 bit/sec. within the same bandwidth using 8-DPSK. 


III. Robustness 


The simplest test of the robustness of a modulation system is the measurement 
of its behaviour in presence of Arbitrary White Gaussian Noise (AWGN). DQPSK is 
known to be more rubust than FSK, though it also has a better spectral effi- 
ciency. For example, to obtain a BER of 10E-4, the required SNR per bit is 
10.7dB when using DQPSK, but 12.3dB when using FSK. DBPSK requires an even 
smaller SNR of 9.3dB in that case, and is thus the most robust mode mentioned. 
It is also important to remember that signals with many levels, e. g. 16-DPSK, 
require more energy per bit than DBPSK or DQPSK. Generally, a compromise has 

to be found between the symbol duration (i. e. the baud rate) and the number 

of bits that each symbol has to carry. Short symbols do require a greater band- 
width, but a high throughput can be achieved with only a few levels per symbol. 
As a result, the signal is more robust against AWGN than a system with the same 
throughput using longer symbols and more levels. On the other hand, short sym- 
bols are very susceptible to time smearing (see below) and require a higher 
bandwidth. DQPSK with 100 baud has proven to be a very good compromise between 
robustness against AWGN and time dispersion, especially if it is combined with 
powerful error control coding. 


Another very important point for a short wave communications system is the 
restistance against multipath effects, which occur if there is more than one 
path between transmitter and receiver. Due to the various delays at the re- 
ceiving end, the combination of the different received signals does not result 
in a copy of the original signal, but in a more or less distorted wave form. 
Three major multipath effects can be distinguished: time dispersion or ‘time 
smearing', frequency dispersion and selective fading. These three effects are 
closely related to each other. They are strong if the frequency used is much 
below the maximum usable frequency, and if the distance is long. A single hop 
path on the 20m band, for example, normally does not suffer from severe multi- 
path effects. However, a DX link on the 80m band at night often provides con- 
siderably strong multipath problems. 

The short term time jitter has a magnitude of up to 5 msec. Larger time smea- 
ring can only be observed under very special conditions of the ionosphere. A 
baud rate of 100 symbols per second has proven to be low enough for almost all 
possible propagation conditions, especially if powerful error control coding 

is applied. 

Frequency dispersion means that the frequency of the original signal is shifted 
on the path between transmitter and receiver. It is the same effect as the so- 
called Doppler shift, which can be observed on signals from low orbit satel- 
lites. The magnitude of the Doppler shift on normal short wave paths is only a 
few Hertz, thus it does not influence ordinary FSK systems. However, the demo- 
dulator of a PSK signal needs a very accurate information on the carrier fre- 
quency in order to work properly. A DQPSK system with a symbol rate of 100 bit/ 
sec. can only deliver a correct output, if the frequency error is less than +/- 
12.5Hz. Automatic frequency tracking must therefore be applied, which can easi- 
ly be done on a DSP. The PACTOR-II signal, for example, can automatically be 
tracked by the PTC-II within an offset range of +/- 100 Hz. Longer symbols and 
more levels of a DPSK signal require a much higher frequency accuracy. For ex- 
ample, a 32 baud 16-DPSK signal, as used in CLOVER-II, needs an accuracy of 
better than 1Hz. Thus even small Doppler shifts deteriorate the demodulation 
process, because it is not possible to track the frequency fast enough at such 
a high accuracy. 

Selective fading, the third multipath effect, mainly influences FSK systems, 


as the channel with lower SNR determines the BER of the whole system, if the 
converter cannot switch to space-only mode. The symmetrical property of a bi- 
nary FSK signal is destroyed by selective fading. PSK modulation is quite ro- 
bust against this effect. 


IV. Intermodulation Products and Crest Factor 


Whenever a signal, consisting of two or more parallel carriers or 'tones', has 
to pass through a non-linear stage, intermodulation products are generated. 
Special attention has to be payed to the third order products, because they are 
located relatively close to the original signal components. The final RF power 
stage(s) of the average Amateur Radio transmitter, are capable of a third order 
intermodulation performance of about -30dB. A two-tone signal with a shift of 
200Hz thus produces third order intermodulation products that are located vir- 
tually within the original bandwidth of the signal. This means that there will 
not be any interference on adjacent channels due to intermodulation effects. 
However, a Signal consisting of four tones that are spaced at 125Hz, will be 
broadened to around 1100Hz of bandwidth at -30dB when passing through the same 
stage. 


Another item that has to be considered is the Crest Factor, which is defined as 
the ratio of maximum signal amplitude to average signal amplitude. Modulation 
systems designed for radio frequencies should always have a low Crest Factor, 
so that the peaks of the signal wave form do not over-drive the final RF sta- 
ges. Among other considerations, the Crest Factor is influenced by the number 
of tones used by a system. The more tones that are used, the more difficult it 
is to get a low Crest Factor. It is in addition, also influenced by the modula- 
tion method. PSK, for example, leads to a lower Crest Factor than Amplitude 
Shift Keying (ASK). 


V. Error Control Coding 


The use of a reliable modulation system is only one of the essential steps 
towards the goal of optimum data transmission over the difficult paths encoun- 
tered on HF radio. Dramatic improvements can additionally be obtained by cor- 
rect preparation of the data before it gets as far as being transmitted by the 
modem. To be effective, this process, known as Error Control Coding (ECC), im- 
poses very high computing demands on the system processor. Actually the final 
limit of achievable transmission reliability depends solely on the processing 
power used for the ECC. The more power available, the closer the theoretical 
throughput limit, the so-called Shannon Boundary, can be approached. 


The basic idea behind this coding is quite simple: A certain number of redun- 
dant bits is appended to the original information that has to be transmitted 
through a noisy channel. The redundant bits are generated from the original 
data by applying special rules, depending on the chosen code. Data and redun- 
dancy then form a new string of bits, which is called a code word. The ratio 
of the number of information bits and the whole length of the code word is 
called code rate. The number of valid code words is obviously less than the 
number of possible code words. A good code and the corresponding encoding pro- 
cess must produce only those valid code words which have a maximum mutual ham- 
ming distance, that means a maximum number of different bits. This maximum mu- 
tual distance then allows code words to be recognized and distinguished, even 


in the presence of received errors. For example, if the valid code words of a 
specific code have a minimum mutual hamming distance of three, each code word 
containing a single error can be corrected, as the only valid code word with 
the greatest similarity then represents the correct one. 


Two main approaches of ECC can be distinguished: block codes and convolutional 
codes. Both always require data interleaving to be effective on channels with 
burst errors. When applying block codes, the message or packet is devided into 
short blocks containing only a few bits. Each short block is then encoded se- 
parately and forms a relatively short code word. Popular block codes are the 
Golay code, the Hamming codes and the Reed-Solomon code. Block codes can easily 
be implemented as they often show a cyclic property and thus do not require 
much processing power. However, they have proven to be relatively weak, espe- 
cially if the BER is high. They are only able to correct a few errors in each 
code word and thus do not provide any benefits in very noisy channels or poor 
propagation conditions. Additionally, it is very difficult to utilize soft de- 
cision when using block codes. Soft decision means that the decoder does not 
only use binary decisions for the error finding process, but also the analog 
values provided from the demodulator section. It works similar to the analog 
Memory-ARQ of PACTOR and requires an ADC or DSP. 

If convolutional codes are applied, the entire message or packet is encoded 

and the resulting code words are longer than the original packet. These codes 
are very powerful, and their efficiency is only limited by processing speed. 
The complexity of a convolutional code mainly depends on the length of the 
tapped shift registers, which work as binary convolver and represent the heart 
of the convolutional encoder. This specific number is called constraint length. 
It provides an upper boundary of the coding gain that can be achieved by a con- 
volutional code. Several methods have been developed for the decoding process 
of these codes. The optimum decoder, which allows maximum likelihood decoding, 
is called the Viterbi-Decoder. Unfortunately, the relationship between con- 
straint length and complexity of a Viterbi-Decoder is not a linear one, but it 
increases exponentially. Real-time applications of Viterbi-Decoders were limi- 
ted to quite short constraint lengths for a long time due to slow processor 
speeds. Nowadays, using the new generation of DSP's, it has become possible to 
apply constraint length 9 or even higher convolutional codes. As a major advan- 
tage of convolutional codes and the Viterbi-Decoder, soft decision may be im- 
plemented and only slightly increases the complexity of the system. PACTOR-II, 
as implemented in the original German PTC-II, applies a convolutional code with 
contraint length 9 and soft decision. 


From forrerj@ucs.orst.edu Fri Jun 16 12:05:46 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id MAA21841 for 
<hfsig@tapr.org>; Fri, 16 Jun 1995 12:05:40 -0500 
Received: from p00.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 

id AA30504; Fri, 16 Jun 1995 10:05:32 -0700 
Message-Id: <9506161705.AA30504@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Fri, 16 Jun 1995 09:15:45 -0800 


To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:408] Help. 


Dear Siddhartha and all the recent subscribers, 


> 

>I have just become a subscriber of this wonderful mailing 
>group and I find a lot of interesting things happening here. 
> 

>This is my first posting to the list. I need info on the 
>following : 

> 

>1. The german pactor level-II modem PTC-II's availability. 
>Whether the modem can be purchased in kit form or whether 
>any documentation on its design is available. 

> 


I think Peter answered that one. 


>2. The PC-PACTOR software to operate Pactor with the AN-93 
>modem which I intend to build. I could locate the PCTOR 
>and download it from the tapr ftp site. Please let me know 
>where from I can get the PC-PACTOR. 


PC-PACTOR -- 
PC-PACTOR for the AN-93 is on ftp.tapr.org /tapr/SIG/hfsig/upload. I have 
not really 
finished the program (ARQ part is incomplete) as at the time I missed some 
crucial details that the Pactor folks (SCS) were reluctant to share. 
However, I did get help from someone else that I used to complete the PSA 
soundcard version. I will finish the PC-PACTOR version when I get a break. 
However, you could certainly use the AN-93 with Tom Sailer's fine program 
that will give you all the modes, including Pactor. It is also on the same 
ftp site. Let us know how it works for you. 


EXTENDED WELCOME -- 
It appears that we have a number of new subscribers after Dayton. Welcome to 
all of you. 


PACTOR II -- 
Thanks Peter for the detailed overview of Pactor II. 


I had many gripes about the Pactor I implementation, especially an 
inappropiate frame synch method and the inablility for automatic link 
re-establishment after failure. I did note, however, that some of these 
weaknesses have been addressed in Pactor II. Maybe this is a winner? Hope so. 


Does anyone perhaps know whether the actual protocol for Pactor II is 
available? Or do one have to pay the licensing fee to obtain that? 


I think we now have a good idea of the basic modulation scheme, signaling 
and ECC, but without the protocol description, experimentor's still cannot 
do it themselves as I found that out the hard way when I experimented with 
my own version of Pactor I. 


EVM56002 -- 
I will have the package including the HF modems (works with PC-TOR or HB9JNX 
software) by Monday (6/19/95). Look in the hfsig/upload area for it 
(EVM56K0.ZIP) . 
There will be a bit more materials about this project shortly. 


73's and keep up the good work. 


--Johan, KC7WW 


From gjones@tenet.edu Fri Jun 16 13:22:21 1995 

Received: from Kay-Abernathy.tenet.edu (Kay-Abernathy.tenet.edu [198.213.2.7]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id NAA22741 for 
<hfsig@tapr.org>; Fri, 16 Jun 1995 13:22:07 -0500 

Received: (from gjones@localhost) by Kay-Abernathy.tenet.edu (8.6.11/8.6.9) id 
NAAOQ9274 for hfsig@tapr.org; Fri, 16 Jun 1995 13:22:03 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199506161822 .NAAQ9274@Kay -Abernathy.tenet.edu> 

Subject: Re: [HFSIG:414] Re: Help. 

To: hfsig@tapr.org 

Date: Fri, 16 Jun 1995 13:22:02 -0500 (CDT) 

In-Reply-To: <9506161705.AA30504@ucs.orst.edu> from "Johan Forrer" at Jun 16, 95 
12:20:36 pm 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 1220 


According to Johan Forrer: 


PC-PACTOR -- 
PC-PACTOR for the AN-93 is on ftp.tapr.org /tapr/SIG/hfsig/upload. I have 
not really 


finished the program (ARQ part is incomplete) as at the time I missed some 
crucial details that the Pactor folks (SCS) were reluctant to share. 
However, I did get help from someone else that I used to complete the PSA 
soundcard version. I will finish the PC-PACTOR version when I get a break. 
However, you could certainly use the AN-93 with Tom Sailer's fine program 
that will give you all the modes, including Pactor. It is also on the same 
ftp site. Let us know how it works for you. 


VV VV VV VV VV VV 


Good News for all those waiting and already on the list for AN-93 modems. 
The volunteer finally finsihed the work and we went to the board shop 


Monday with the updated board. 3 weeks for that and then another week or so 
to kit and mail. 


Letters were mailed to all the people on the AN-93 waiting list eariler this 
week. 


The updated AN-93 modem support FSK and AFSK output and the new design 
allows on-board alignment with a PC program (so no test equipment is 
required). 


There will be 100 kits done. I believe we have taken orders for 35+ to date. 
Cheers - Greg, WD5IVD 


From chbrain@dircon.co.uk Sat Jun 17 03:56:15 1995 

Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id DAA29556 for 

<hfsig@tapr.org>; Sat, 17 Jun 1995 03:56:11 -0500 

Received: by felix.dircon.co.uk id AA14092 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 17 Jun 1995 09:57:28 +0100 

Message-Id: <199506170857 .AA14092@felix.dircon.co.uk> 

Received: from ad044.pool.dircon.co.uk(193.128.231.44) by amnesiac via smap (V1.3) 
id sma014085; Sat Jun 17 09:57:01 1995 

X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sat, 17 Jun 1995 08:10:38 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 

Subject: TI DSK and the ISA Bus 


Hi all, 
Has anyone got a circuit to interface a TMS320C50 to a PC ISA bus. As you 
know the TI DSK is pretty unusable for real applications due to the method 
it talks to the P.C. I was thinking that as all the bus is available on the DSK 
it should be possible to mount it onto a P.C prototype card and communicate 
with it using either the DSP parallel ports or via shared memory. Still 
using the 
serial port for downloads and debuging. 


I am still struggling with my MIL-STD-188-141A 8ary modem, on the DSK 

and I have two main problems, the communications described above and 

the fact that the TI DSK free assembler is not a macro assembler so it is 
difficult 

to write properly structured code (well for me)! (or to pinch their example FFT 
algorithms!) 


On a slightly different tack, the swiss red cross are evaluating pactor II 

and are very impressed with it. 

It sounds an ideal platform for an ALE controller, so anyone know how to contact 
the german manufacturers? 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From danie.brynard@pixie.co.za Sat Jun 17 06:21:54 1995 

Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id GAA30163 for 
<hfsig@tapr.org>; Sat, 17 Jun 1995 06:21:45 -0500 

Received: from pixie.co.za ([196.11.63.7]) by foxbat.pix.za (8.6.12/8.6.12) with 
SMTP id NAAQ1920 for <hfsig@tapr.org>; Sat, 17 Jun 1995 13:19:45 +0200 
Date: Sat, 17 Jun 1995 13:19:45 +0200 

Message-Id: <199506171119 .NAAOQ1920@foxbat.pix.za> 

X-Sender: pak03226@pixie.co.za (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 

Subject: Re: [HFSIG:401] Re: some questions 


>Dear Ilkka, 

> 

>To be honest, I don't really know what "NVIS" means - can anyone help? 

> 

>Just for interest sake, you may find it useful to browse the files in 
>ftp.tapr.org /tapr/SIG/hfsig/upload 

>There are quite a bit on HF propagation; as related to it's affects on 
>digital transmissions. 

> 

>You will also find two Pactor programs there, one that I wrote "PSATOR/PSA- 
>PACTOR" for the sound card DSP, and another one by Tom Sailer, HB9JNX, that 
>will work with a number of different types of modems, including something 
>that you can put together on your new EVM56002. 

> 

>I have ported the Alef Null kernel to the EVM56002 and thus allows you 

>to run any of the codes that run on the DSPCARD4. This includes 1200 baud 
>BELL 202 and 9600 baud PAM (G3RUH) style modems. The DSP kernel includes 
>all HDLC and KISS interfaces, so all you need to have is the EVM and 

>one of the flavors of NOS/KA9Q on your PC. It's really neat stuff. For the 
>HF side of things, I have some HF modems for the EVM as well. 

> 

>Using the ported kernel, you will also be able to participate in the 
>experimental high speed HF modem work. There also are a number of 
>excellent noise reduction programs using Wiener, LMS and correltion- 
>based algorithms. The latter is by Pawel (SP9VRC) and is a joy to use on 
>CW. 

> 

>I am working on putting together the schematic for my version of the EVM's 


>radio interface and will post the complete package (with the kind 
>permission of the Alef Null group) on the net. Watch for the announcement if 
>you are interested. 

> 

>Think this answers most of your questions. Feel free to e-mail me directly 
>about the EVM56002. 

> 

>73's 

> 

>--Johan, KC7WW 

>(email: forrerJ@ucs.orst.edu) 

> 


Hi Johan. Kan nie wag nie.... 
danie brynard 
> 


From forrerj@ucs.orst.edu Sun Jun 18 13:46:37 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id NAAQ6235 for 
<hfsig@tapr.org>; Sun, 18 Jun 1995 13:46:34 -0500 
Received: from p08.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 

id AA15333; Sun, 18 Jun 1995 11:46:28 -0700 
Message-Id: <9506181846.AA15333@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu (Unverified) 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Sun, 18 Jun 1995 10:56:52 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: EVM56002 program package 


Hi all, 


I have uploaded evm56k0.zip to ftp.tapr.org /tapr/SIG/hfsig/upload. 
We gratefully acknowledge those that gave their kind permission. 


Hope you enjoy it. 
73's 
--Johan, KC7WW 


From paulr@hagar.udc.neweast.ca Mon Jun 19 09:52:27 1995 
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id JAA15341 for 
<hfsig@tapr.org>; Mon, 19 Jun 1995 09:52:20 -0500 
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 

id AA20202; Mon, 19 Jun 95 14:52:03 GMT 


Received: from cc:Mail by ccsmtp.udc.neweast.ca 

id AA803589734; Mon, 19 Jun 95 11:54:42 nst 
Date: Mon, 19 Jun 95 11:54:42 nst 
From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 
Message-Id: <9505198035 .AA803589734@ccsmtp.udc.neweast.ca> 
To: hfsig@tapr.org 
Subject: pactor 2 


The other day a Posting was made here about Pactor 2 (3parts). Does 
anyone know the phone number and email address for the company 
mentioned but not named in the article? 


I am extremely interested in getting more info on the PTC-II, 
including price. Possibly for a commercial application. 

Also I am looking for the availablity and price of the Packet Radio 
Modules. 


Paul Russell 
paulr@neweast.ca 


P.S. Its too bad this mailing list eats the address of the mail 
originator.. 


From FORRERJ@frl.orst.edu Mon Jun 19 10:28:17 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA15690 for 
<hfsig@tapr.org>; Mon, 19 Jun 1995 10:28:14 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id IAA07959 for <hfsig@tapr.org>; Mon, 19 Jun 1995 
08:27:26 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Mon, 19 Jun 95 8:33:50 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 19 Jun 95 8:33:41 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 19 Jun 1995 08:33:31 PST8PDT 
Subject: Re: [HFSIG:416] TI DSK and the ISA Bus 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <2DEF98E2261@frl.orst.edu> 
Hi Charles, 


I do not know of an easy solution to put that DSK on the ISA bus. You may 
want to consider using one of JDR's ready-made prototyping cards. I have 
used those in the past for building PC-based projects. The cards come in 
either 8-bit or 16-bit flavors and contains all the ISA-bus glue logic. The 
remainder of the cards are then perforated to take wire-wrap parts. The 8- 
bit cards costs some $40 price range. The 16-bit cards are a little more 
expensive, but not much. 


The prototyping cards are quite useful - I have built (seems like a long 
time ago) a wire-wrapped dual 68010 co-processor card on one of these cards 
and used a DMA-based host-coprocessor interface. 


A bit more along the HF digital lines: let us know how things are 
progressing on the parallel modem - what kind of demodulation filtering 
method are you using? 


73's 


--Johan 

From chbrain@dircon.co.uk Mon Jun 19 14:41:02 1995 

Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id 0AA17843 for 

<hfsig@tapr.org>; Mon, 19 Jun 1995 14:40:42 -@500 

Received: by felix.dircon.co.uk id AA28644 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Mon, 19 Jun 1995 20:39:21 +0100 

Message-Id: <199506191939.AA28644@felix.dircon.co.uk> 

Received: from ad033.pool.dircon.co.uk(193.128.231.33) by amnesiac via smap (V1.3) 
id sma028618; Mon Jun 19 20:38:55 1995 

X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Mon, 19 Jun 1995 18:52:08 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 

Subject: Re: [HFSIG:420] Re: TI DSK and the ISA Bus 


>A bit more along the HF digital lines: let us know how things are 
>progressing on the parallel modem - what kind of demodulation filtering 
>method are you using? 

> 

>73's 

> 

>--Johan 

> 

> 

Hi Johan, 

I am working along the lines that Adrian G4ZHZ used in his piccolo modem, 
the main problem is implementing an FFT as all the examples I have are done 
using macros, I am trying to write a simple macro expander to take the TI 
examples and convert them into something the DSK understands. The other 
problem is of course the wretched interface to the DSK, I think it will break my 
coding skills to implement the modem and expect a software uart to work as 
well !! 


I will investigate one of those prototype cards, also they have bought a TI 
sun based development system at work with both an assembler and C compiler, 


I am negotiating access to it as you read this !!!! 


I have been busy with a Linux system as well so that has eaten some of my time 


and I am also QRV on H.F from my car now, I have the auto ATU in the trunk and 
have a Pro-am 14Mhz vertical on a roof rack that took me ages to ground 
properly. 


I have also been playing with Phil's KA9Q Viterbi code on my Linux system, 
it works great, next thing is to understand what his macros do ! 


Regards Charles 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From sid@doe.ernet.in Mon Jun 19 15:03:09 1995 

Received: from sangam.ncst.ernet.in (sangam.ncst.ernet.in [144.16.11.1]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA18085 for 

<hfsig@tapr.org>; Mon, 19 Jun 1995 15:03:01 -0500 

Received: (from uucp@localhost) by sangam.ncst.ernet.in (8.6.12/8.6.6) with UUCP 

id AAAQ4596 for hfsig@tapr.org; Tue, 20 Jun 1995 00:23:49 +0530 

Received: from mahavir.doe.ernet.in by doe.ernet.in (4.1/SMI-4.1-MHS-7.0) 
id AA18830; Mon, 19 Jun 95 18:17:38+050 

Received: by mahavir.doe.ernet.in (4.1/SMI-4.1-MHS-7.0) 
id AA25145; Mon, 19 Jun 95 18:16:53+0530 

Date: Mon, 19 Jun 1995 18:16:51 +0530 (GMT+05:30) 

From: Siddhartha Bhattacharjee <sid@doe.ernet.in> 

Subject: Re: [HFSIG:414] Re: Help. 

To: hfsig@tapr.org 

In-Reply-To: <9506161705.AA30504@ucs.orst.edu> 

Message-Id: <Pine.3.89.9506191855 . B24453-0100000@mahavir> 

Mime-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Johan, 


I am sorry I could not locate the file PC-PACTOR in the site. 
I also could not locate the Tom Sailer's software which 
you have referred to in your last mail. 


I would appreciate if you could let me have the details. 


The price of the PTC-II is little too much. I understand that 
that the sophistication which goes into it is really very 

great. The protocol looks great but it remains to be seen as to 
how does it perform under a given band condition. I was also 
very much impressed by the article on G-TOR published in the 

May 1994 issue of the QEX. Simplied architecture of the modem 


and the price/performance ratio is also required to be looked into 
to make it popular among the hams. 


I would request a feedback from one of the PTC-II users ( I do not 
know if there is a subscriber of this mailing list ) to say 
few words about its performance. 


Thanks to all the contributors. 
Sid, vu2sid in New Delhi, India. 


From FORRERJ@frl.orst.edu Mon Jun 19 15:32:02 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA18435 for 
<hfsig@tapr.org>; Mon, 19 Jun 1995 15:31:58 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id NAAO9715 for <hfsig@tapr.org>; Mon, 19 Jun 1995 
13:31:11 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Mon, 19 Jun 95 13:37:34 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 19 Jun 95 13:37:24 
PST8PDT 
From: "Johan Forrer" <FORRERJ@fr1l.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 19 Jun 1995 13:37:15 PST8PDT 

Subject: Re: [HFSIG:421] Re: TI DSK and the ISA Bus 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <2E4099210E5@frl.orst.edu> 
Hi Charles, 
Appears that you are a busy fellow indeed! 


Sorry I cannot help much with the C50' macros. Would it be possible to use 
Bison or other parser-generator to do that? 


The Linux connection is interesting. I had a go at it about a year ago, but 
gave up after realizing that it was such an incredible moving target. When 
I started following Pawel's work on HF modems, I realized that the whole 
issue of the modem and it's eventual place in a network, needs some thought, 
worthy of exploration. I have had some success with Pawel's modem - BTW, 
the way he does it is to use the Leonid kernel calls to communicate with 
NOS. This way he has a universal software interface. This is a novel idea 
(at least I think so). The version of JNOS that I played with ran 

under DOS, but one must realize that folks that build networks dont use 

DOS any more, anyway you need to keep up with recent software. 

Then went on to try OS/2 with very mixed results. I decided to 

remove OS/2 totally from my system after an awful crash (running NOS) that 
destroyed both FAT's on both my hard drives (there were other reasons too). 
I then decided to revisit Linux and been quite amazed by how stable it is. 
The main objective at present is to get a DSP sound card device driver 


functional that will enable one to download DSP algorithms and 

allow development of applications that feeds into Linux's networking 
capabilities. However, as you can imagine, things have gotten quite involved 
now: Not only is it knowing the DSP and programming DSP applications, but 
the Linux device drivers and dealing with TCP/IP as well. 


I welcome further comments, ideas, and suggestions on this theme. 
73's 


--Johan, KC7WW 


From FORRERJ@frl.orst.edu Mon Jun 19 15:50:47 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA18627 for 
<hfsig@tapr.org>; Mon, 19 Jun 1995 15:50:43 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id NAAO9755 for <hfsig@tapr.org>; Mon, 19 Jun 1995 
13:39:36 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Mon, 19 Jun 95 13:46:00 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 19 Jun 95 13:45:48 
PST8PDT 
From: "Johan Forrer" <FORRERIJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 19 Jun 1995 13:45:48 PST8PDT 
Subject: Re: [HFSIG:422] Re: Help. 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <2E42D747399@frl.orst.edu> 
Dear Siddhartha, 
Try the following: 


ftp.tapr.org /tapr/software_lib/terminal/PCTOR302.ZIP ---- PC-TOR 3.02 
ftp.tapr.org /tapr/SIG/hfsig/upload/jnx_2.zip --- HB9IJNX software. 


You may also find this (and perhaps leater versions) on: 


ftp.ucsd.edu /hamradio/packet/tcpip/incoming directory, or in the "DSP" 


or "packet" directories. Things move around a bit. 


Hope this helps. 


--Johan, KC7WW 

From chbrain@dircon.co.uk Mon Jun 19 16:38:27 1995 

Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA19081 for 

<hfsig@tapr.org>; Mon, 19 Jun 1995 16:38:21 -0500 

Received: by felix.dircon.co.uk id AAQ2968 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Mon, 19 Jun 1995 22:39:36 +0100 

Message-Id: <199506192139.AA02968@felix.dircon.co.uk> 

Received: from ad004.pool.dircon.co.uk(193.128.231.4) by amnesiac via smap (V1.3) 
id sma002954; Mon Jun 19 22:39:24 1995 

X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Mon, 19 Jun 1995 20:52:35 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 

Subject: Re: [HFSIG:423] Re: TI DSK and the ISA Bus 


>Hi Charles, 

> 

Not only is it knowing the DSP and programming DSP applications, but 
>the Linux device drivers and dealing with TCP/IP as well. 

> 

>I welcome further comments, ideas, and suggestions on this theme. 

> 


>73's 

> 

>--Johan, KC7WW 
> 


Yes I know exactly what you mean, 

I have been through that route as well, I had OS/2 running on a partition, 
I have 
got rid of it now. 

I have two machines one downstairs in the shack, on which I run DESQview/X 
and a second machine upstairs that runs Linux. I use the 'Xterminal' in the 
shack 
to log into the Linux ssytem over an ethernet, which I am in the process of 
expanding around the house! The people at work think I am nuts. 


As far as the macros are concerned, yes they could be done with lex/yacc. Yet 
another thing to learn! 


I have started to port all my ‘'homebrew' software to the Linux environment, its 
an ideal Hams OS and it great to have the source, there are a number of 
things I would like to play with like X.400 mail, but I have to concentrate 
my efforts 
on one thing at a time. 


I would like to get some propagation S/W like ioncap to run under Linux. I have 
also heard of other Hams using cron tasks to scan radios etc. It seems as if 

it would be not too difficult to build a sofisticated system using building 
blocks such as Linux. 


I am also trying to learn SASD using Cadre Teamwork at work, it would be nice 
to get some CASE tools for Linux as well. 


Well this ain,t really to do with HFSIG but certainly interesting. Things 
seem to be quite quiet here recently. 


I must admit I have learn't a lot listening to this sig then reading up 
afterwoods, 

I have actually found a use for what they tried to teach me at university! I 
have 

been going through all my basic math books again and also the ones on 
modulation etc. Thats what it is all about isn't it. 


Regards Charles. 


"projects don't slip, they just catch up with reality 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From chbrain@dircon.co.uk Mon Jun 19 17:09:39 1995 

Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id RAA19478 for 

<hfsig@tapr.org>; Mon, 19 Jun 1995 17:09:31 -0500 

Received: by felix.dircon.co.uk id AAQ3756 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Mon, 19 Jun 1995 23:10:45 +0100 

Message-Id: <199506192210.AA03756@felix.dircon.co.uk> 

Received: from ac042.pool.dircon.co.uk(193.128.230.42) by amnesiac via smap (V1.3) 
id sma003747; Mon Jun 19 23:10:22 1995 

X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Mon, 19 Jun 1995 21:23:31 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 

Subject: Re: [HFSIG:423] Re: TI DSK and the ISA Bus 


Hello again Johan, 


Well I have been poking about on ftp.ti.com and have found a file 

called 5xdskspc.exe which is a compressed file containing an audio 
spectrum analyser for the DSK. Unlike the code shipped with the DSK 

which outputs via the D/A port this code talks back via the serial port 
and has a graphical display on the P.C. I haven't tried it yet 

but it maybe suitable for an FFT and certainly the C++ routines provide 
info on how to download code to the DSK from the P.C. I have a look at it 
tommorrow. 


Regards Charles (off to my bed!) 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From frode@dxcern.cern.ch Tue Jun 20 02:32:23 1995 
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id CAA23809 for 
<hfsig@tapr.org>; Tue, 20 Jun 1995 02:32:19 -0500 
Received: from dxcern.cern.ch by dxmint.cern.ch 
id AAQ7486; Tue, 20 Jun 1995 09:32:16 +0200 
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA29089; Tue, 20 Jun 1995 09:32:15 +0200 
Date: Tue, 20 Jun 1995 09:32:14 +0200 (MET DST) 
From: Frode Weierud <frode@dxcern.cern.ch> 
To: hfsig@tapr.org 
Cc: hfsig@tapr.org 
Subject: Re: [HFSIG:419] pactor 2 
In-Reply-To: <9505198035.AA803589734@ccsmtp.udc.neweast.ca> 
Message-Id: <Pine.ULT.3.91.950620092202 .27837A-100000@dxcexrn.cern.ch> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Mon, 19 Jun 1995, Paul Russell wrote: 


> Date: Mon, 19 Jun 1995 10:06:18 -0500 

> From: Paul Russell <paulr@hagar.udc.neweast.ca> 
> To: hfsig@tapr.org 

> Subject: [HFSIG:419] pactor 2 


The other day a Posting was made here about Pactor 2 (3parts). Does 
anyone know the phone number and email address for the company 
mentioned but not named in the article? 


I am extremely interested in getting more info on the PTC-II, 
including price. Possibly for a commercial application. 

Also I am looking for the availablity and price of the Packet Radio 
Modules. 


VV VV VV VV WV 


Paul Russell 
paulr@neweast.ca 


P.S. Its too bad this mailing list eats the address of the mail 
originator.. 


VV VV VV MV 


The company that sells the PTC-II is: 

SCS, Spezielle Communications Systeme GmbH 
Roentgenstrasse 36, 

D-6450 Hanau, Germany. 

Phone/FAX: +49 6181 23368 


This is also the home address of DL2FAK, Dr. Thomas Rink. 


73's Frode 

Frode Weierud Phone : 41 22 7674794 

CERN, SL Fax : 41 22 7679185 

CH-1211 Geneva 23, Switzerland E-mail : frode@dxcern.cern.ch 


From JALOCHA@chopin.ifj.edu.pl Thu Jun 22 04:39:01 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id EAA16676 for 
<hfsig@tapr.org>; Thu, 22 Jun 1995 04:38:45 -@500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id LAA15983 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Thu, 22 Jun 1995 11:08:50 +0200 

Date: Thu, 22 Jun 1995 11:08 GMT+1 

Subject: Re: [HFSIG:392] HFSIG activities 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <190754A320218C58@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


Hello everybody, 


Just to report little progress I have just made: I have coded 

a 12-tone DQPSK modem into the DSPCARD4. 

12 tones, each carries 125 baud, QPSK (4-PSK) => 2 bits/symbol 

=> total data rate = 12*2*125 = 3000 bits/second. 

The tones are spaced by 187.5 Hz, the first is 500 Hz, the last 
is 2687.5 Hz. The whole bandwidth is 100-200 Hz (on both sides) 
larger than that. The modem seems to work better than my previous 
multi-tone DBPSK one. 


Infact it's up to the user to define how many tones he need 
and where should they be placed - the code is flexible in this respect, 


so one can easily adapt the data rate to the available bandwidth. 


The modem's encoder and decoder is based on the 128 point FFT 
at 8000 Hz sampling. 


The modem works on my DSPCARD4 with the build-in KISS-TNC 

or in the test mode so you can spy on various internal data. 

In principle it should work too on the EVM56002 with the Johan's 
BIOS.ASM - I am going to try this. My other applications did work 
so I don't expect a problem there. 


No FEC yet, but I am thinking of it. First I should make 
some provision for soft decisions, then interleave, then FEC. 


The other thing to think about: how to make such FFT decoder 
"tuneable" so it could accept a signal shifted in frequency. 

For the moment the decoder can detect a mis-tune, but is not able 
to correct it. 


Pawel 
From FORRERJ@frl.orst.edu Thu Jun 22 10:51:26 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA20115 for 
<hfsig@tapr.org>; Thu, 22 Jun 1995 10:50:58 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id IAA25692 for <hfsig@tapr.org>; Thu, 22 Jun 1995 
08:37:28 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Thu, 22 Jun 95 8:43:59 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 22 Jun 95 8:43:51 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Thu, 22 Jun 1995 08:43:45 PST8PDT 
Subject: Re: [HFSIG:428] Re: HFSIG activities 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <3272701710E@fr1l.orst.edu> 
Pawel, 


Excellent! If you have the foundation of something that has promise, 
perhaps it is time that we can divide the task up and let a couple of folks 
work on it. Just off the top of my head I can think of a couple of them: 


1) Tuning indicator 

2) Frequency tune-up/correction 

3) ECC 

4) Simple KISS-based user-interface instead of NOS so that we can 
get at testing the modem. The idea is that NOS compatibilty be 
retained for future networking applications. 


These are quite general in nature, so you probably still could change things 
at the very low implementation level and use the higher levels of 
code. 


What do you think - anyone interested in working on some of these topics? 


73's 
--Johan, KC7WW 
From RHIII@delphi.com Thu Jun 22 13:23:46 1995 
Received: from bosig.delphi.com (bosig.delphi.com [192.80.63.9]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id NAA21874 for 
<hfsig@tapr.org>; Thu, 22 Jun 1995 13:23:41 -0500 
From: RHIII@delphi.com 
Received: from delphi.com by delphi.com (PMDF V4.3-9 #10880) 
id <QLHSODIFMF9OI94GYEZ@delphi.com>; Thu, 22 Jun 1995 14:23:34 -0400 (EDT) 
Date: Thu, 22 Jun 1995 14:23:34 -0400 (EDT) 
Subject: FAQ ? 
To: hfsig@tapr.org 
Message-id: <Q1HSODIFMF9K94GYEZ@delphi. com> 
X-VMS-To: INTERNET"hfsig@tapr.org" 
MIME-version: 1.0 
Content-type: TEXT/PLAIN; CHARSET=US-ASCII 
Content-transfer-encoding: 7BIT 


Tremendous ideas and excellent writing on this list. 
Is there a FAQ supporting it ? 


---Richard/NT2Z 

From paulr@hagar.udc.neweast.ca Tue Jun 27 08:17:12 1995 

Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id IAA11271 for 

<hfsig@tapr.org>; Tue, 27 Jun 1995 08:16:45 -0500 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AAQ8228; Tue, 27 Jun 95 13:15:49 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA804275155; Tue, 27 Jun 95 10:45:43 nst 

Date: Tue, 27 Jun 95 10:45:43 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Message-Id: <9505278042 .AA804275155@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:428] Re: HFSIG activities 


>>The other thing to think about: how to make such FFT 

decoder "tuneable" so it could accept a signal shifted in 
frequency. 

For the moment the decoder can detect a mis-tune, but is not able 
to correct it. 


Pawel<< 


Try a Zero-Padded Larger FFT (Say 512pt) 
8000/512 = 15.62Hz/bin 


Although a zero-padded FFT will not resolve two tones that occupied 

the same bin in a smaller FFT into their individual components, it will resolve 
where the peak power point is of a single tone to a more acurate point. Thus by 
calculating the magnitude on the bins adjacent to the bin expected to carry the 
data tone, you can choose which one you should interpret as best centred and to 
use for phase calculation. 


So a 512pt has 4 times more bins than a 128pt, allowing you to choose a bin 
closer to the true location of the received signal. You can thus compensate for 
radio offset without having to shift frequency with something like a hilbert 
transform, although I'm uncertain which would be more efficient in code 
execution time. 


I don't know how much error would occur in choosing to use a more offset bin 
part way through a packet (in my simulations it was negligible with the angle in 
the zero-padded FFT the same as in the smaller FFT), but I suspect the radio's 
frequency offset drift to be VERY slow. Thus choose the offset during the 
syncronization, and stick with it for the rest of the packet. 


Note also that all the channels in the parallel modem would be shifted by the 
same amount of freq/bins (at the audio level since freq offset is at the RF 
level). So calculating the peak power point by adding together the magnitudes of 
the corresponding bins at each channel over several symbols will average out 
which way the radio is offset even in the presence of noise. 


How are you calculating the phase angle? I have an article on how to doa 
simplified arctan approx for a TMS32010 if its useful to anyone. I'm certain it 
could be recoded to any DSP. 


Paul Russell 
paulr@neweast.ca 


From JALOCHA@chopin.ifj.edu.pl Tue Jun 27 10:30:26 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA12663 for 
<hfsig@tapr.org>; Tue, 27 Jun 1995 10:30:05 -0500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id RAAQ9541 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Tue, 27 Jun 1995 17:28:37 +0200 

Date: Tue, 27 Jun 1995 17:28 GMT+1 

Subject: Re: [HFSIG:431] Re: HFSIG activities 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <3BE65FO9E022085A@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


>Try a Zero-Padded Larger FFT (Say 512pt) 
> 8000/512 = 15.62Hz/bin 


> 

>Although a zero-padded FFT will not resolve two tones that occupied 

>the same bin in a smaller FFT into their individual components, it will resolve 
>where the peak power point is of a single tone to a more acurate point. Thus by 
>calculating the magnitude on the bins adjacent to the bin expected to carry the 
>data tone, you can choose which one you should interpret as best centred and to 
>use for phase calculation. 


So you select the best tone, and then you may possibly be mis-tuned 

by up to 7.8 Hz - this is still a lot... In term of phase changes: 

7.8 Hz is about 49 radians/second, I transmit 125 symbols per second, 
thus during one symbol the phase would turn by 0.39 radian (22 degrees) 
- this is a lot, almost half way to make a bit error (45 degrees). 

I know I could make even longer FFTs and get more finer steps... 

I agree this is one way to deal with the problem. 


I was actually thinking of a way to "interpolate" between the FFT bins. 
If a tone falls say right inbetween bin 7 and 8 which combination 

of the two you need to get the data as if the tone falls just right 
into the bin's center ? 

In other words how can you frequency-shift the frequency-domain data 
by an arbitrary step ? I know how to do it with the time-domain data... 


>So a 512pt has 4 times more bins than a 128pt, allowing you to choose a bin 
>closer to the true location of the received signal. You can thus compensate for 
>radio offset without having to shift frequency with something like a hilbert 
>transform, although I'm uncertain which would be more efficient in code 
>execution time. 


Hilbert transform can shift the frequency ? This might be something 
I am looking for ? 


>I don't know how much error would occur in choosing to use a more offset bin 
>part way through a packet (in my simulations it was negligible with the angle in 
>the zero-padded FFT the same as in the smaller FFT), but I suspect the radio's 
>frequency offset drift to be VERY slow. Thus choose the offset during the 
>syncronization, and stick with it for the rest of the packet. 


This is my current "research" direction. I am thinking of making a header 
such that the receiver may quickly acquire the frequency shift and 

the symbol sync. - possibly both at same time. After the header has passed 
only minor adjustments are to be made. 


>Note also that all the channels in the parallel modem would be shifted by the 
>same amount of freq/bins (at the audio level since freq offset is at the RF 
>level). So calculating the peak power point by adding together the magnitudes of 
>the corresponding bins at each channel over several symbols will average out 
>which way the radio is offset even in the presence of noise. 


There is a little problem that the bands of the tones partially overlap 
or are at least well packed so you may not be able to find a clear peak. 
The could be overcome by sending only every second tone for the header. 


>How are you calculating the phase angle? I have an article on how to doa 
>simplified arctan approx for a TMS32010 if its useful to anyone. I'm certain it 
>could be recoded to any DSP. 


I don't really compute the phase angle but compare the two succesive I/Q 

vectors. If A(a vector) is what I got from the current FFT and B is what 

I got from the previous FFT I compute: X=Bx*A and Y=B'xA. 

* means the vector-dot-product, ' means turning a vector by +90 degrees. 

X and Y (infact a vector) contains the information to find one the di-bit 
transmitted. 


Anyway, I am certainly interrested in a fast way to compute 
the phase from the the X/Y values. 


I made more progress with the intersymbol crosstalk: I parametrized 

the window's shape and by minimizing the total crosstalk in terms 

of the parameters (I used praxis.zip found in msdos/math on most 

FTP sites) I found an optimal shape with crosstalk at 0.6E-4 

(it used to be 1E-1). The price for much lower crosstalk was the first 
side-lobe at about -10dB level... but futher side-lobes are below -50dB 
(measured with a soundcard + FREQ4 software). 


Pawel 

From JALOCHA@chopin.ifj.edu.pl Tue Jun 27 10:53:38 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA12800 for 
<hfsig@tapr.org>; Tue, 27 Jun 1995 10:53:27 -0500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id RAAQ9829 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Tue, 27 Jun 1995 17:52:27 +0200 

Date: Tue, 27 Jun 1995 17:52 GMT+1 

Subject: Re: [HFSIG:429] Re: HFSIG activities 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <3F38291EC022085A@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


>Excellent! If you have the foundation of something that has promise, 
>perhaps it is time that we can divide the task up and let a couple of folks 
>work on it. Just off the top of my head I can think of a couple of them: 


>From my point of view these are the major problems: 


1. Tunning correction: 10 Hz mis-tune seems to be real bad, and 20 Hz 
makes the signal unreadable even for 100 dB S/N :-) 
We probably need to make it automatic at least within a small range. 
For network application, the packet's header should be made for 
fast auto-retune and symbol-sync. 


2. FEC with soft-decisions... how do we judge on the "strength" 
of the received symbol ? 
Here comes a related issue: if you want to compare the "strength" 


of symbols coming from different tones, you should normalize 
them somehow - this is trivial if you use division, but division 
is rather costly (in terms of clock cycles) for the DSPs. 


So an algorythm is needed which least divisions possible. 

I find my radio's (YEASU FT757-GXII) audio characteristic to be very 
unperfect: 2500 Hz tone is 2-3 times lower in amplitude than 

the 800 Hz tone (this is just the receiver). Well, this could be 
"perfect" for voice, but not for data. 


Another issue related to "band equalization" is the symbol 
synchronization. For the moment I am taking the average symbol 


shift from all 12 tones. But in general you want to keep the proper sync. 


even if one or more tones get overcome by a strong carrier-type 


interference. Thus you should weight the shifts from different carriers. 


Pawel 
From paulr@hagar.udc.neweast.ca Tue Jun 27 13:23:56 1995 


Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 


dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id NAA14425 for 

<hfsig@tapr.org>; Tue, 27 Jun 1995 13:23:51 -0500 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AAQ9841; Tue, 27 Jun 95 18:23:48 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA804293635; Tue, 27 Jun 95 15:53:30 nst 

Date: Tue, 27 Jun 95 15:53:30 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Message-Id: <9505278042 .AA804293635@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Pawel? 


Pawel, 


I'll send the file about angle calculations, but my mail server 
is eating your email reply address, please send it. The 13K file 
is maybe a bit long for posting here - unless several people want 
it?? 


I tried asking the tapr.org listserver for the subscribers, but 
it indicates that all of us are hidden names - Oh well (Guess 
that helps keep down people using our names for other 
purposes...). 


>>>Here is the current list of non-concealed subscribers: 
>>>Total number of subscribers: 144 (0 shown here) 


There are definitely more subscribers than I thought. 


Paul 
paulr@neweast.ca 


From nash@camail.ca.nmp.nokia.com Wed Jun 28 04:19:35 1995 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by 


dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id EAA22821 for 

<hfsig@tapr.org>; Wed, 28 Jun 1995 04:19:30 -0500 

Received: from mgw.nmp.nokia.com (mgw.nmp.nokia.com [131.228.233.85]) by 

noknic.nokia.com (8.6.9/8.6.9) with SMTP id MAA29723 for <hfsig@tapr.org>; Wed, 28 

Jun 1995 12:18:57 +0300 

Message-Id: <199506280918 .MAA29723@noknic.nokia.com> 

Received: from caits1.ca.nmp.nokia.com by mgw.nmp.nokia.com with SMTP 
(1.38.193.4/16.2) id AAQ5931; Wed, 28 Jun 1995 12:18:55 +0300 

Received: from cadsp1.ca.nmp.nokia.com by camail.ca.nmp.nokia.com with SMTP 
(1.37.109.14/16.2) id AA121751042; Wed, 28 Jun 1995 10:17:22 +0100 

Date: Wed, 28 Jun 1995 10:17:22 +0100 

From: Adrian Nash <nash@camail.ca.nmp.nokia.com> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:433] Re: HFSIG activities 


Hi Pawel 


I have a few suggestions which have worked in my MFSK modem which I suppose is 
very Similar in some respects. 


>1. Tunning correction: 10 Hz mis-tune seems to be real bad, and 20 Hz 
makes the signal unreadable even for 100 dB S/N :-) 

We probably need to make it automatic at least within a small range. 
For network application, the packet's header should be made for 
fast auto-retune and symbol-sync. 


VVV WV 


There is a simple equation which uses the magnitudes (NOT magnitude squared) of 
adjacent FFT points to calculate frequency error to within the separation of the 
points. I have used this in my MFSK modem to track frequency error with some 
success. However, I can't remember the formula off the top of my head! I'll get 
back to you with this. I think Johan Forrer may be able to help you with this one. 
He originally suggested the idea to me and I then produced a MathCad simulation 
which worked, so then I coded it up in my modem and it works fine for tracking. 


I use a Hilbert transform coupled to a complex demodulator to shift the audio 
down to zero-IF in the complex plane. The tracking loop is closed by applying 
the exact offset in Hz to the NCO algorithm. 


>2. FEC with soft-decisions... how do we judge on the "strength" 

of the received symbol ? 

Here comes a related issue: if you want to compare the "strength" 
of symbols coming from different tones, you should normalize 
them somehow - this is trivial if you use division, but division 
is rather costly (in terms of clock cycles) for the DSPs. 


VVVV WV 


For soft decisions, I use the following equation which unfortunately does have 
a divide in it. However, the divide only needs to be performed once in the case 
of an MFSK modem or 12 times in your case for the 12 best signals: 


2 
2 I (best) 


\ I 
/ «kK 


ie, accumulate the magnitude squared results (1%2+Q%2) then find the best 

(ie greatest) magnitude. Divide one by the other. C(n)%2 is then a good indicator 
of the "goodness" or confidence of the particular tone. and is fine for 

soft decision use. On my ADSP2101-based modem, the divide is done in floating 
point and takes about 30 cycles (about 1.5us on ADSP2115) including conversion 
back to fixed point. 


Regards 
Adrian 
From forrerj@ucs.orst.edu Wed Jun 28 10:47:53 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id KAA25279 for 
<hfsig@tapr.org>; Wed, 28 Jun 1995 10:47:47 -0500 
Received: from p04.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 
id AA24218; Wed, 28 Jun 1995 08:47:14 -0700 
Message-Id: <9506281547 .AA24218@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Wed, 28 Jun 1995 07:58:21 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:432] Re: HFSIG activities 


Pawel, 


>Hilbert transform can shift the frequency ? This might be something 
>I am looking for ? 
> 


It may be useful to use a Hilbert transform especially if your demodulator 
require I/Q paths, i.e. doing complex FFT's. You do need, however, some good 
low pass filters to go with it. All these computational blocks eats at your 
machine ticks, however. If you can fit it in, that will be excellent. We had 
some discussion about this topic under "HF channel simulator". 


>I made more progress with the intersymbol crosstalk: I parametrized 
>the window's shape and by minimizing the total crosstalk in terms 

>of the parameters (I used praxis.zip found in msdos/math on most 

>FTP sites) I found an optimal shape with crosstalk at 0.6E-4 

>(it used to be 1E-1). The price for much lower crosstalk was the first 
>side-lobe at about -10dB level... but futher side-lobes are below -50dB 
>(measured with a soundcard + FREQ4 software). 

> 


For interest sake, could you perhaps tell us a bit more about the FREQ4 
software - where to obtain it etc. These analytical methods and tools are 
useful to know about. 


I also had an interesting e-mail from Adrian, G4ZHZ about his progress with 
his Piccolo (MFSK) project. As you all know, he is using a DSP sound card 
and he tells me that he has done a lot of work on the DSP kernel (that part 
of the DSP code that runs in real time, in parallel with other DSP 
activities - mainly to orchestrate tasks and communicate with the host PC). 
This was necessary before he could start porting his exsisting Piccolo code 
to the DSP. These extensions also are quite general, as a matter of fact he 
built a very nice audio signal processing box using that. This audio 
processor is intended for use with your HF radio and includes: various 
filters (narrow CW etc.), denoisers, and a software BFO to resolve slightly, 
off-tune SSB or CW. One can quite easily see how these different functions 
plays a role in his modem developments. The sound procesor, though would be 
a handy piece of code in its own right. I am looking forward testing it out. 
Good work Adrian! 


73's 
--Johan 


From GTaylor@ecad00.avionics.itt.com Wed Jun 28 14:03:31 1995 
Received: from ittingw.itt.com (ittingw.itt.com [151.190.254.250]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id OAA27788 for 
<hfsig@tapr.org>; Wed, 28 Jun 1995 14:03:28 -0500 
Received: from ccmail.avionics.itt.com by ecad0Q.avionics.itt.com (5.65/U1trix3.0- 
C) 

id AA23104; Wed, 28 Jun 1995 14:59:55 -0400 
Received: from cc:Mail by CCMAIL.AVIONICS 

id AA804376746; Wed, 28 Jun 95 14:41:14 EST 
Date: Wed, 28 Jun 95 14:41:14 EST 
From: "Taylor, Gregg" <GTaylor@ecad00.avionics.itt.com> 
Message-Id: <9505288043 .AA804376746@CCMAIL .AVIONICS> 
To: hfsig@tapr.org 
Cc: Henry_Sonntag_at_ITTAVI@CCMAIL.AVIONICS.itt.com 
Return-Receipt-To: GTaylor@ecad00.avionics.itt.com 
Subject: ADDRESSING PROBLEM 


From 72253.2602@compuserve.com Thu Jun 29 10:29:36 1995 
Received: from arl-img-4.compuserve.com (arl-img-4.compuserve.com [198.4.7.4]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA04599 for 
<hfsig@tapr.org>; Thu, 29 Jun 1995 10:29:33 -0500 
Received: by arl-img-4.compuserve.com (8.6.10/5.950515) 
id LAA27535; Thu, 29 Jun 1995 11:29:31 -0400 
Date: 29 Jun 95 11:27:27 EDT 
From: Peter Schulze <72253.2602@compuserve.com> 
To: TAPR-HFSIG <hfsig@tapr.org> 


Subject: Freq anal. with soundcards 
Message-ID: <950629152726_72253 .2602_EHJ164-1@CompuServe. COM> 


> For interest sake, could you perhaps tell us a bit more about the FREQ4 
> software - where to obtain it etc. These analytical methods and tools are 
> useful to know about. 


There are several freeware programs around that allow spectrum 
analysis with soundcards : 


1.- MICFFT 

by Craig Walsh (walsh@biovx1.DNET.NASA. GOV) 

This one works on almost any ‘compatible' soundcard. 

Craig told me that he is working on a windows version. 

The most current Version is 1.2. 

Micfft can be found in the Compuserve Soundblaster forum (MICFFT.ZIP). 
There was an article by DK4ZC about using this program to analyse 

HF digital signals in the March issue of the ADRS Digital 

Journal. 

MicFFTs main limitation is slow execution and a FFT length of max 256 
points. On the other hand it is very stable, has nice graphics and works on 
about every Hardware. MicFFT is freeware. 


2. FREQ3, FREQ4 and SPECGRAM 


by Philip VanBaren 

Internet: phillipv@engin.umich.edu 
Compuserve: 71214,2302 

1845 Lake Lila Dr. Apt. C3 

Ann Arbor, MI 48105 


..also Freeware. 

can be found on Compuserve as well, in the same forum (.ZIP). 
Freq3 is an older Version but comes with sourcecode (Borland C++). 
FREQ3 was written for the Pro Audio Spectrum 16. FREQ4 also 
supports the Soundblaster cards. 

Main advantages against MicFFT: 

- FFT Length variabel, max. 2048 points 

- a lot faster (31ms for a 1024 FFT on a 486/33) 

- with PAS cards up to 44KHz at 16 bit Resolution 

- SPECGRAM has an excellent graphical Display on SVGA. 

- lots of commandline options 

- FREQ3 sourcecode avaiable. 

(thanks to Christoph dl4rcg who supplied the FREQ info to me some time ago) 


3. Another usefull program is Mathplot 
by Phillip H. Sherrod 

4410 Gerald Place 

Nashville, TN 37205-3806 USA 
615-292-2881 (evenings) 

Internet: 76166.2640@compuserve.com 
(shareware, uncrippled registration $25, also on the CIS soundblaster forum). 


Mathplot is a mathematical function plotting system which allows you to 
enter functions using ordinary algebraic notation and immediately plot them. 
Cartesian, polar, and parametric functions are supported, and up to four 
functions may be displayed simultaneously. A variety of built-in functions 
are provided. Plotting commands may be executed from command files. 


Maybe someone who is on Compuserve as well can download these programs and 
post them here on the TAPR system ? 

Unfortunatly i can't do that as i am ona very (!) 

expensive (-2400 baud X25) line, 

where i am charged 15 cents per kilobyte. 

So moving these files out of Cis and up here 

would cost me a little fortune. The Datahighway did not 

arrive in Africa yet(?).... 


73 Peter TY1PS 


From forrerj@ucs.orst.edu Fri Jun 30 09:25:16 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id JAA17775 for 
<hfsig@tapr.org>; Fri, 30 Jun 1995 09:25:05 -0500 
Received: from p05.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 

id AA26115; Fri, 30 Jun 1995 07:24:56 -0700 
Message-Id: <9506301424.AA26115@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Fri, 30 Jun 1995 06:36:11 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:438] Freq anal. with soundcards 


Peter, 


Thanks for the interesting summary. Time that I explore some of those 
mentioned programs. 


For interest sake, I may just add that the sound card FFT scope (on 
hfsig/upload) will also be helpful, so will Tom McDermot's program for the 
DSP-93, that does the same thing. I am just not certain about whether the 
frequency resolution is sufficient. 


--Johan, KC7WW 


>> For interest sake, could you perhaps tell us a bit more about the FREQ4 
>> software - where to obtain it etc. These analytical methods and tools are 
>> useful to know about. 


> 

> 

>There are several freeware programs around that allow spectrum 
>analysis with soundcards : 

> 

>1.- MICFFT 

>by Craig Walsh (walsh@biovx1.DNET.NASA.GOV) 

>This one works on almost any ‘'compatible' soundcard. 

>Craig told me that he is working on a windows version. 

>The most current Version is 1.2. 

>Micfft can be found in the Compuserve Soundblaster forum (MICFFT.ZIP). 
>There was an article by DK4ZC about using this program to analyse 

>HF digital signals in the March issue of the ADRS Digital 

>Journal. 

>MicFFTs main limitation is slow execution and a FFT length of max 256 
>points. On the other hand it is very stable, has nice graphics and works on 
>about every Hardware. MicFFT is freeware. 


> 

>2. FREQ3, FREQ4 and SPECGRAM 

> 

>by Philip VanBaren 

>Internet: phillipv@engin.umich.edu 


>Compuserve: 71214,2302 

>1845 Lake Lila Dr. Apt. C3 

>Ann Arbor, MI 48105 

> 

>.also Freeware. 

>can be found on Compuserve as well, in the same forum (.ZIP). 

>Freq3 is an older Version but comes with sourcecode (Borland C++). 

>FREQ3 was written for the Pro Audio Spectrum 16. FREQ4 also 

>supports the Soundblaster cards. 

>Main advantages against MicFFT: 

>- FFT Length variabel, max. 2048 points 

>- a lot faster (31ms for a 1024 FFT on a 486/33) 

>- with PAS cards up to 44KHz at 16 bit Resolution 

>- SPECGRAM has an excellent graphical Display on SVGA. 

>- lots of commandline options 

>- FREQ3 sourcecode avaiable. 

>(thanks to Christoph dl4rcg who supplied the FREQ info to me some time ago) 
> 

>3. Another usefull program is Mathplot 

>by Phillip H. Sherrod 

>4410 Gerald Place 

>Nashville, TN 37205-3806 USA 

>615-292-2881 (evenings) 

>Internet: 76166.2640@compuserve.com 

>(shareware, uncrippled registration $25, also on the CIS soundblaster forum). 
>Mathplot is a mathematical function plotting system which allows you to 
>enter functions using ordinary algebraic notation and immediately plot them. 
>Cartesian, polar, and parametric functions are supported, and up to four 
>functions may be displayed simultaneously. A variety of built-in functions 
>are provided. Plotting commands may be executed from command files. 

> 


>Maybe someone who is on Compuserve as well can download these programs and 
>post them here on the TAPR system ? 

>Unfortunatly i can't do that as i am ona very (!) 
>expensive (-2400 baud X25) line, 

>where i am charged 15 cents per kilobyte. 

>So moving these files out of Cis and up here 

>would cost me a little fortune. The Datahighway did not 
>arrive in Africa yet(?).... 

> 

>73 Peter TY1PS 

> 

> 

> 


